Both the problem statement and proposal use the term "strawman". I think using "strawperson" would be more inclusive language.

There are many cases where companies leverage federated identity flows to enable SSO across their properties where these properties are NOT enterprise or education based.

For example...

mail.example.com may use login.example.com via OpenID Connect to provide authentication and authorization to the mail service. And, because of the principles of least privilege, the authorization token issued to mail may be unique to mail (say a cookie written on the mail.example.com domain). When the user goes to visit finance.example.com, the finance site may bounce the user through idp.example.com (again using OpenID Connect) in order to get authentication and authorization tokens that are scoped specifically to finance.example.com. Note that in many deployments the domains won't all be *.example.com even though they are all first party relying parties.

Given these are all first party interactions, it seems weird for the browser to intermediate with a lot of additional UX.

Additionally, as a relying party, it is very important to ensure there is clear communication with your users regarding issues with their identity. For example, the user's identity may have been compromised and the IDP needs the user to work through a recovery flow to get the user back in control of their account. Or the user may have forgotten their password and needs to gain access via some additional method. All these flows are carefully tailored by the IDP to ensure clarity for the user and to help the user get back into their account as seamlessly and quickly as possible.

I'd like to add these use cases to the list of deployment methodologies that need to be solved with this effort.

The latest changes in https://github.com/samuelgoto/WebID#the-consent-stage don't look workable for an IDP and will largely affect user convenience and expectation.

IDPs rely on a direct user interaction (IDP UI) for a user to authorise information sharing with an RP and also to validate the RPs identity. The proposal raises some fundamental concerns:

• How should an IDP validate/trust that an authorisation was given by a specific user?
• More importantly, how would the IDP even be sure which RP is receiving the data? In a usual SSO flow RPs must be authenticated by the IDP for obvious reasons, which requires prior registration / agreements on secrets etc. Even lightweight approaches based on CORS won't work without RP knowledge prio to transmitting any data
• How would an IDP know and record which data the RP is requesting? (scopes/claims)

Users rely on an IDPs service across devices / different browsers / different sessions for an RP on a single browser. This interaction is unknown to the browser thus user interactions will not meet user expectation:

• As already noted in the proposal the IDP will have prior user interactions that the browser is not aware of, a user could have registered with an RP on a different device / prior session and already approved to share specific information to an RP. Establishing the browser UI as proposed will basically eliminate the main advantages of an IDP as the user will see repetitive prompts to share the same information over and over again.
• Conceptually one needs to differentiate between a registration and a following login, which one is currently happening during a call to the IDP API cannot be known to the browser thus he cannot present a fitting interaction without relying on the IDP (which in turn needs to be ware of the RP to do so).
• I don't see how one could conceptually decouple this a suggested without breaking user expectation.

The prior approach of wrapping the IDP Interaction with the user into an identity-specific API/Wrapper looked much more balanced and workable for the stated goals to minimize the divergence from existing federated identity user experience. The control of the authentication/authorisation flow must remain with the IDP thought (without duplication by the browser)

The browser can very well observe the interaction of the user with the IDP and also inform the user about an RP session state with an IDP. Ultimately its the users choice to leverage an IDP with an RP which is completely unrelated to the browser itself, I do believe this choice should be respected and don't see how this decoupling could work out. IDP Tracking might be scenario, but it should not dictate the whole design of this API (with the noted impacts) as the IDP is a service chosen by the user

Related issues: #27

The inability to reason over which applications a user is accessing is incompatible with enterprise requirements, particularly from a security and auditing perspective. "Conditional access" – enterprise-driven access controls based on the user, device, application and permissions involved in an authentication or authorization - is a primary use case for enterprise IdPs, used for:

1. Requiring multi-factor and/or device auth when specific apps are visited
2. Managing consent between RPs in the case of OAuth 2.X
3. Blocking access to disallowed applications
4. Requiring authentication for some applications to occur on certain networks
5. Preventing OAuth phishing attacks by observing how applications are used within an ecosystem (critical for both consumer and enterprise IdPs)

Additionally, tracking which applications corporate accounts are used with is a table-stakes expectation for administrators, for auditing and security purposes.

The consumer privacy value provided by IdP anti-tracking measures is clear and inarguable. At the same time, enterprises cannot keep their workforce and businesses safe in these scenarios without an enlightened IdP, and will refuse to adopt WebID if these services are unavailable.

An option for user consent within browser-controlled UX to release the application identifier to the IdP, with the IdP denying access without the release, appears to be the way forward. As a first cut of text – "✅ idp.example.com can know that you’re signing into example.payportal.com."

It seems like the IDP could provide the UA with this information at login time instead (via an API, response header, whatever). As currently presented, it seems to contact the IDP (with credentials) every time the user visits a site which could possibly be logged into (before they actually log in). If it is necessary, it would be great to briefly explain why.

I don't follow the reason for contacting the IDP at login time either; the main document alludes to backward compatibility issues, and I've tried to understand the slides for the "delegation-oriented" system but I don't quite follow. If something new is being invented, then at least for the login (no permission delegation) case, isn't all that's needed a certificate from the IDP that can be used to sign nonces for the RP? Similarly can't the UA track which origins need to be notified of logout?

testing

Related issues: #34 #14

There are two common patterns of nested, different-domain sites that both require the user to authenticate with an IdP – "first party" and "cross-party". These are largely work and school (enterprise/education) scenarios from our experience, but "first party" embedding is becoming more popular within consumer applications as well. In both cases, the removal of third party cookies to be replaced with WebID breaks authenticated scenarios.

"First-party" embedding

In this development pattern, an application is constructed of multiple iframes, sourced from different domains, for the purposes of content reuse, security, or due to legacy – as an example, teams.microsoft.com hosts an iframe containing sharepoint.com in order to display documents. They work in conjunction with each other, using a single user’s auth state. Under WebID, it appears that each sub-frame (sometimes 10-15 frames per app) would need to individually request a sign in, triggering a cascade of UX.

This solution, however, is unblocked via the use of First Party Sets, as each domain in use in the app is ultimately owned by one entity, who can mark them all as belonging to the same "family". A single successful WebID invocation in the top level frame should unblock silent WebID invocation by all child frames that share a first party set with the top level frame (assuming it’s for the same user and IdP). This ensures that even when the IdP is not in a first party set with the application, only a single user gesture is required to make the application work.

"Cross-party" embedding

In the cross-party scenario, common in education as well as consumer applications, party A embeds an application from party B in their web page, with the intent of application B accessing data on behalf of a user. This is seen across the web in the form of Disqus comments, embedded YouTube or Stream videos, and learning management system (LMS) integrations (Issue #34). The top-level frame may not sign in a user at all, but the child frame is expected to have SSO in order to function.

In this scenario, we propose a pattern similar to that of the Storage Access API – embedded applications can invoke WebID on user interaction with the frame. While this represents a deterioration in the SSO experience, it is required for user privacy. Embedded applications should be able to silently invoke WebID in future sessions, partitioned on a parent-frame basis. Thus, users will always see themselves signed into Party B’s app on Party A’s site, but not on Party C’s site.
If Party B is a complex application in its own right using "first-party" embedding, it’s expected that a single invocation of WebID by Party B’s top-most frame is sufficient to allow all of that frame’s children to silently invoke WebID as well.

The current WebID proposal only hides at which RP a user is logging in from the IdP until the user gives consent to log in using the selected IdP. In particular, the attack scenario sketched in IDP1 is not mititgated (IdP tracks where a user signs-in). This proposal only addresses a slightly different attack scenario, i.e., that any IdP can always track where a user is about to log in.

One possiblity to address problem IDP1 can be similar to the solution that we propose in the SPRESSO SSO protocol. In this protocol, the IdP receives an encrypted string (which we call the tag). The tag contains a nonce and an identifier for the RP. The identifier of the RP, however, we mainly needed to work around browser restrictions. As WebID is probably not subject to such restrictions, it might be even sufficient to just use a plain nonce instead, i.e., just run a challenge/response between RP and IdP.

See https://www.sec.uni-stuttgart.de/research/wim/ for information on the protocol design of SPRESSO. In our research, we also analyzed several other SSO protocols (including BrowserID). You can find our results on this page as well.

@kenrb - thanks for consolidating this topic and picking up the challenges I raised in #24

A few remarks on OpenID:

Subject IDs in OpenID:

OpenID contains an explicit definition of directed identifier in terms of the sub value - SubjectIDTypes.

sub values are either pairwise (i.e. directed) or public (i.e. global). In case an IDP declares its sub values to be pairwise it is also mandatory within the spec that they are not reversible by anyone but the IDP.

IDPs publicly declare their config for sub values within the OpenID discovery - for example"subject_types_supported":["pairwise"]

Please note that

• IDPs must be aware of the sub value and its relation to the user account because they use it to persist user choices w.r.t. to the respective RP based on that (is the user already registered with an RP, which claims were approved by the user, ...) - I assume this is what is meant by verifiably directed identifiers not being compatible with the protocols
• IDPs typically have a notion of the legally responsible entity (which they manage via out-of-band RP registrations) that is related but not identical to a specific URL (Brand) - see also the discussion around first party sets, about the relation between URLs and legal entities. IDPs have mechanisms defined to manage this (same for Android / iOS for example)

Research collaborations and academic institutions around the world rely on multilateral identity federation to enable single-sign-on and authorization on the web as well as via dedicated applications and domain-specific tools. Here are three typical examples:

• Go to https://nature.com and follow a discovery UX flow to find your institution’s identity provider (IdP) and proceed to login. Attributes will be shared (via a federation protocol - typically SAML or OIDC) which will be used to determine if you and/or your institution have authorization to access specific resources.
• Go to a shared wiki space (e.g., https://wiki.refeds.org) and follow an IdP discovery interface to find your institution and login.
• Go to a shared certificate service (e.g., https://wiki.geant.org/display/TCSNT/TCS+Participants+Sectigo) and follow an IdP discovery interface to find your institution and login. Attributes will be shared to determine if you are authorized to generate and sign certificates on behalf of your organization.

The problem?

Low-level primitives in the browser that are being optimized for considerations of personal privacy as a result of widespread misuse of cross-site tracking, namely third party cookies, link decoration, and postMessage, are commonly used to simplify the user experience in identity provider discovery flows. Identity provider discovery flows as deployed in R&E federations are inherently privacy-preserving.

Can First Party Sets help?

FPS is a formulation to allow user identity to span related origins, where consistent with privacy requirements. Identity federation, however, is not just about a single IdP supporting a set of RPs; it is about a trust fabric that allows collaboration between multiple IdPs and RPs.

In the academic federation model, the user is going to traverse multiple origins in order to access resources. In the US, the InCommon federation has nearly 4000 IdPs and 6000 RPs. A user that visits the RP will have to go through a discovery flow to find their IdP. Ideally, they will use that discovery flow once and have their choice reflected during visits to any of the other 5999 RPs.

For the browser to correctly intermediate the identity flows, it must understand the underlying federation of trust between all these parties to ensure the correct user experience. Today, FPS does not describe these kinds of relationships.

Academic Federation Policies

Academic federations create a multi-lateral trust fabric between thousands of IdPs and RPs, heavily dependent on both SAML and OAuth protocols. Policies are multilayered, happening at the federation, IdP, and RP levels. No one group has control over user browser configuration or use.

Academic federations are different from consumer SSO in several key ways:

• In academic federations, as is the case in many other regulated industries where federation is deployed as a mechanism for controlled information sharing, global identifiers are often both mandated by law as well as expected by users (eg for receiving citation credits in publishing scenarios).
• Users act as employees while outside the context of their immediate organization and its official services. An employee of university X is using services from research collaboration Y which is part of an international consortium where use of resources (and hence identification) is not subject to individual needs and wishes but rather the purview of legislation and international treaties.

WebID thoughts

WebID is a formulation to preserve federation under tighter privacy controls. However:

Observation #1: Academic identity federations have a different set of privacy expectations compared to both consumer and enterprise identity federations.
Observation #2: WebID’s design largely depends on a deployment structure that isn’t exactly applicable to academic identity federations: there are thousands of IdPs interacting with thousands of RPs across multiple protocols

Consent Arguments

In some situations, the institution hosting the IdP controls the consent for information release; RPs may not directly ask the user for information. For instance, GDPR section 6 lists the set of conditions under which personal information may be processed. One of those is “free and informed consent”. In most cases where the data subject is acting outside the purely personal sphere (as in consumer identity), consent cannot be freely given. For instance, if a grad student is tasked to write a piece of code and the official policy is to use GitHub then the GitHub consent screen is arguably illegal in the EU since the user is not able to deny consent. Similar situations arise in all federation use-cases and it is for this reason very uncommon for R&E services in the EU to rely on consent as a legal foundation for processing PII.

Enterprises rely on identity federation to enable single-sign-on on the Web today. Here is a typical example:

1. Sign-in to https://corporation.com with your corporate credentials
2. Buy stuff with your corporate credit card
3. Go to report expenses on https://www.expenses-sass.com/
4. Sign-in with your corp accounts on expenses-sass
5. Report expenses tied to your corporate account

The problem?

Unfortunately, step (4) depends on many low level primitives that are being tightened up as a result of cross-site tracking, namely third party cookies, link decoration and postMessage.

Can First Party Sets help?

FPS is a formulation to allow user identity to span related origins, where consistent with privacy requirements. However, the intent of FPS is to bundle origins within a unifying organization. For example, https://google.com, https://google.co.uk, and https://youtube.com are owned by the same entity, as are https://apple.com and https://icloud.com, or https://amazon.com and https://amazon.de.

Back to our original example, it is clear that https://corporation.com and https://www.expenses-sass.com/ are not owned by the same organization, but rather a contracted service provided by two different organizations, so doesn't fit the FPS model.

Enterprise Policies?

The idea behind enterprise policies is that enterprises issue machines for their employees to do their work, and in doing so, have a tighter level of control and expectations about their use.

Enterprise policies are policies set by enterprise admins for machines that the corporation issues for their employees. These policies change a variety of browser behavior.

Enterprise SSO is different from consumer SSO in two ways:

• In enterprise SSO, it is critical to share global identifiers. For example, expense reporting and vacation reporting is a typical contracted service that a corportation delegates, but clearly needs to join your identity with your corporation.com identity.
• In enterprise issued machines, there is an expectation that employees will be using them for work and that their employer is aware of what they do on corporate resources.

The idea then, is to add enterprise policies that enable enterprise admins to set policies that lower the browser interventions for a specific set of origins.

One proposal is to allow enterprise admins to say “this specific origin IDP.example can communicate with other origins”. With that permission, IDP.example is then responsible for making a determination of which domains it trusts to integrate with.

For example, corporation.com could have an enterprise policy setting accounts.corporation.com as the IDP, which would allow things like https://www.expenses-sass.com and https://www.vacations-sass.com to pass through but disallow other unintended origins.

One shortcoming of enterprise policies is that they will probably need to be set specifically for each browser the employees of a corporation are allowed to use, so there is an extra cost involved to admins to manage their fleet of devices.

WebID and Enterprise Profiles?

WebID is a formulation to preserve federation under tighter privacy controls. However:

• Observation #1: Enterprise SSO has arguably a different set of privacy expectations compared to consumer’s identity federation. Specifically, enterprises issue machines that have a different set of expectations of use.
• Observation #2: WebID’s design largely depends on a deployment structure that isn’t exactly applicable to enterprises: there are thousands of IDPs rather than a handful and each IDP typically connects with a handful of RPs rather than thousands. So, from a deployment perspective, enterprise policies have a much faster turn around compared to redeploying all of the enterprise IDPs/RPs.

In BYOD (bring your own device) use cases, employees use their own personal devices to access corp resources. One interesting idea to be explored is using WebID to make the set up enterprise policies, possibly even kicking off a partitioned enterprise profile.

The delegation-oriented model diagram has multiple issues with numbered labels. First, 3 is missing. Second, 5 is missing too. Finally, it has 6, 6a, and 6c, but no 6b.

Some flows the provisioning state should probably integrate with:

1. The user may not be logged into the IdP on this device yet.
2. The user may be logged in with multiple accounts and need to pick one.
3. The user may be logged in with some accounts but want to add a new account.
4. The IdP may want the user to reauthenticate to the selected account.

(1) probably wants some provision for the IdP to open a window prior to the consent stage. (2) and (3) could also be IdP-controlled, though if we build account selection into the system, that gives room to solve the NASCAR flag problem in a later extension. (4) looks a lot like (1), though there is also the possibility of moving it post-consent.

https://threadreaderapp.com/thread/1135716764174753798.html

I may have missed discussion on these 2 topics in other issues or in the spec itself but it's not clear to me how this specification would protect from the following:

• Wouldn't the IDP be able to access all the emails forwarded through the proxy email address? Wouldn't this be a worse security position to be in as it centralized (or at least moved to a few IDP) all email flows when it comes to governments wanting to access those objects?

• Wouldn't the use of directed identifiers also open up issues when it comes to trade dispute between parties, such as recently Apple and Epic, where you might lose access to a large chunk of your users? Shouldn't there be a mechanism to allow exporting the mapping of the emails to prevent being held for ransom by a few big companies managing identity?

cheers!

I am creating this issue mostly because a discussion in this area would be helpful.

@samuelgoto has added a proposal to try to offer a path forward for front-channel logout use cases once third-party cookies are deprecated.

The basic idea is for the browser to infer an identity federation relationship between the RP and the IdP and then allow special credentialed requests from the IdP to the RP based on that. A few questions come out of this, and community feedback would be great.

1. How constrained can the logout URI be and still be useful for IdPs? Can this just be a protocol and host name, or is a path required? (I am guessing a path is needed in most deployments.) If we don't allow query parameters (i.e. iss and sid, which are optional in the spec), would this still be useful?
2. How much of a problem is it that this is not being done with an iframe? The consequence is that the RP can't return script to do something like clear anything in LocalStorage.
3. Is an API needed for this at all? If the user agent is satisfied that a good faith RP/IdP relationship has been established then why not just relax 3p cookie restrictions for the RP's origin within a page loaded by the IdP?
4. As @samuelgoto mentions, the means of establishing that relationship is an open question. He provides a couple of rough ideas but we haven't gone very far yet in assessing feasibility, use case coverage, and abuse resistance attached to them.

The browser should provide extensible points for other wallet applications to act as the user’s Identity Agent and handle all flows related to IDs and data disclosure.

IDP tracking is a still a major concern of this WebID proposal. A few docs here mention Persona's design for browser-issued JWT's as a solution. But, it would require RP changes to handle JWT's signed by the browser, which would be harder to change, and result in a longer adoption window.

To be better informed on that problem, we'd like to understand what length of adoption window we might expect from RP's. Can we get some data on the adoption lengths that have been observed for other similar IDP changes?

Thanks for putting together a great resource on the problem space. I’d like to take a step back and broaden the solution space. Looking back at the history of OpenID and OAuth, they had aspirations of ubiquity but ended up trending towards enterprise use cases and grew in complexity accordingly. Mozilla persona had more of a consumer focus but I think tried to be too novel and likewise got tripped up by complexity.

There seems to be a conventional wisdom that RPs want/need profile data/authorization but I feel this theory is mostly untested because developers have never been given a good low-complexity authentication-only option to experiment with. So I’m proposing a solution that returns to the goal of eliminating passwords without trying to solve every identity use case imaginable.

Implementation and UX

1. User visits example.com and inputs [email protected] to a sign up/login field.
2. example.com may interpret that string like an account in RFC7565 or WebFinger. example.com performs a fetch with credentials to https://example.net/.well-known/acctauthn/?acct=bob%40example.net&nonce=knswprfcmqzxxxxxxxxxxxxxx
3. The user agent recognizes this precise well known URL structure and adjusts the fetch mode to omit the origin header.
4. example.net responds based on request credentials (response format TBD). Response headers include Access-Control-Allow-Credentials: true and Access-Control-Allow-Origin: * The IdP could have a real-time approval feature that uses the nonce to help identify the request.
5. In this special fetch mode the user agent accepts the above header combination and allows example.com to read the response. If response was unsuccessful example.com may instruct the user to login to example.net or fallback to treating [email protected] as an email and proceed with traditional login flows.

Analysis

• The classification problem is handled because the well known URL allows the browser and IdP to narrowly opt in to the special fetch behavior.
• RP origin is hidden from IdP. The IdP would have timestamps of requests but would need RP collusion to correlate.
• Directed identifiers are not achieved within the protocol itself but this goal appears mutually exclusive with RP hiding. If we can only have one, RP hiding seems the better choice since:
  • Many scenarios will give linkable info anyway (phone, shipping addr)
  • Directed identifiers can be achieved out of band with IdP issuing multiple ids and username managers similar to current password managers.
• Reusing the syntax of an email address helps adoption.
  • Since the mailto: scheme is rarely used in UIs it fits with users current understanding of an account at a domain and doesn’t try to introduce a new concept like logging in with a URL.
  • Easier for IdPs that are email providers to communicate the new capability.
  • Easier for RPs to build a coherent login flow that optionally uses federation.
  • Enables IdPs that are not email providers to help bootstrap the protocol.
  • The above points underpin a belief that RPs will be able to build an experience with no redirects/popups/iframes and that improvement will overcome resistance to broad adoption of federation.
• The protocol can be deployed without browser support. Requests would follow normal CORS rules and expose the origin. No worse than current OAuth. Browser support would just be privacy enhancement.
• Service discovery or redirection of the IdP URL was left out of the example steps for conciseness. While WebFinger comes to mind as a discovery mechanism, it's desirable to have a narrow URL space to apply the new fetch mode, so discovery should probably be protocol specific within the same well known URL.
• Creating a new name for broad federation is hard. Fortunately this protocol would mostly be transparent to the user so shouldn’t require a catchy user friendly name that is equally vague and confusing. AcctAuthn is descriptive of the mechanism and the relation to RFC7565 and a highly unique string making it search engine friendly for developers.

@samuelgoto @kenrb

In addition to the already discussed flows there are additional ones which typically have bespoke implementations, but are quite relevant here:

1. Session Discovery: Allowing a publisher to determine if there is any active user on this device (prior authentication with the IDP happend) - this is highly use-full to adress challenges like NASCAR and allowing the publisher to engage with users based on the IDP choice. Information can be binary, no need to share any user information. This is used with nytimes/medium with Google as an IDP for example, we have similar mechanism.
2. Auto-Sign In: Based on explicit user opt-in per publisher, a user might want to automate the sign-in procedure. That means after authentication with the IDP, visiting a site with the respective opt-in set the user would be signed in automatically. I think this is also a Google IDP feature, we have similar mechanism.

I could think of making

1. part of the publisher side API, as it would be quite simple technically. Another option would be trust tokens, the use case would be similar to calling document.hasTrustToken(IDP) although this seems to be a bit over-engineered given we could just extend the API explicitly.
2. would need consideration in the flows as it relates to skipping parts of it after user choice.

world

test

https://en.wikipedia.org/wiki/WebID

Moving this into a separate issue from #12

The directed e-mail claim feature requires clarification (the privacy goal is clear) (https://github.com/WICG/WebID/blob/master/design.md#directed-basic-profile)

• given RPs use e-mail addresses to communicate out-of-band with users, who is responsible for generating the addresses and proxying these messages?
• It seems hardly achievable to build a proper setup for this without the IdP supporting this type of directed e-mail natively including the e-mail proxy/forwarding features (as @davidben mentions, user won't be interested / or recognise these directed e-mails)
• making this a mandatory requirement is a really high bar in terms of effort for IDPs, more so because they might not all be e-mail service providers themselves.
• Even if the IdP would be willing to support it, it would be hard to achieve if the IdP is not also in direct control of the top-level e-mail domain (security consideration, address conflicts, ....). They could off course use a dedicated proxy domain only for that purpose, but that seems way beyond the idea of just changing a JS-side integration for IDP and not breaking compatibility
• There seems to be a lot to consider to make this happen, given the e-mail is used for a lot of scenarios specifically also account recovery etc.

As I understand WICG's WebID, it shares some goals with RWW/Solid's WebID (identity) and Solid OIDC (authentication). Please bear in mind #41 so to not conflate different uses of "WebID".

Call for review: the Solid OIDC spec (ED) https://solid.github.io/authentication-panel/solid-oidc/ by the Solid Community Group: https://www.w3.org/community/solid/

From your perspective, what's the delta/overlap between WICG's WebID and Solid's WebID + OIDC? Which aspects of Solid OIDC can potentially be native to the browser (re this repo)?

Would a meeting between the two CGs help?

When a user encounters a site that support an IDP for which the user has an account but for which they are not currently logged in, it's not currently clear to me how the user flow is supposed to work in terms of getting signed into the IDP so that they can proceed with the RP sign in.

Is the RP site supposed to ask the user to nav away and/or open a new tab to sign into the IDP site directly before returning to the RP site? That would be unfortunate loss of context and be a significant speed bump for users.

I'd imagined there might be some flow where the site might actually want to present a list of 1 to 10 IDPs they support and let the user indicate which one they actually want to try. If not signed in, the WebID flow could allow the IDP to offer a sign-in page.

We should also think about how things should work if the user is signed in with IDP 1 but for that specific RP wants to use IDP 2 even though they have not yet logged into IDP 2 in that browser session.

If we do end up having a model where the WebID flow itself has a sign-in option, implementers should think about through what mechanism browser password extensions should be able to interact with the dialog.

The explainer is unreadable when GitHub is in dark mode. Consider adding a background to the images.

It is likely that integrations between RPs and IDPs will exchange different sets of information depending on the RP use case. Some IDPs may need to know the RP identity for every account created that involves sharing certain types of information, e.g. in order to provide management and audit capabilities (e.g. data deletion requests as required by GDPR, revocation of long-lived OAuth capabilities). A more lightweight login that is auth only, without attribute exchange, might not need that. Ultimately I think this requires that the trust framework policy declaration proposed for .well-known/webid needs to be for the pair of RP+IDP, and not globally for the IDP.

It does raise an interesting question of how to check for such a policy without revealing the RP identity to the IDP. Perhaps the RP can declare that it needs an RP specific policy, and the IDP generic one is the fallback for ceremonies not-so-annotated.

The proposal is currently to add a new credential type to CredentialsContainer (implied by the use of navigator.credentials.get()).

This is going to be confusing for two reasons:

1. There is already a FederatedCredential in CredentialsContainer. Creating a second FederatedCredential with a (presumably) slightly different name but dramatically different behaviour is clearly not ideal.
2. This doesn't actually store a credential, which is what CredentialsContainer currently does, viz. this would be the only type with get() calls but no corresponding store() calls. This is stretching the existing abstraction pretty far.

AFAICT the reason to use CredentialsContainer is that WebID is a related concept (obtaining information for the purpose of user authentication) but if that is the only reason then I think the above reasons are a strong case for using a new construct.

world

test

The DID URI scheme and data format (Decentralized Identifiers (DIDs) v1.0 (w3c.github.io)) support all the same flows being represented in the WebID proposal.

In order to support all types of IDs that can be exchanged between parties, we should align ID URIs and their generation/resolution/management in accordance with the DID URI scheme and data model. We will need to support truly decentralized DIDs anyway, so the risk of not doing this in a unified way here may require us to implement a different superset of APIs for DIDs, some of which will overlap various functions present in the WebID proposal.

Many user agents/web browsers allow a user to associate a federated identity with their browser profile, and some host operating systems allow 1+ federated identities to be associated with the user's account and shared with installed applications.

It would be beneficial if WebID allowed for the promotion of those identities known by the UA and host OS to WebID as selectable identities within its login form, without requiring the user to reenter those credentials.

Additionally, if WebID does allow for the promotion of these preexisting identities to be promoted to the login form, it would follow that we should provide the ability for users to choose if new identities that they authenticate with via WebID should be saved back to the UA (if the profile allows for it) or the host OS (if the federated login type is supported).

Currently in the federated identity landscape of today end-user identities are mostly scoped/tied to the IDP that creates and manages them. This can be a problematic relationship because end-users can become somewhat beholden to their IDP. Recently, there has been increased interest and exploration into how to establish identities that can outlive or be ported between their providers by leveraging cryptographically verifiable identifiers for end users (e.g public keys, public key fingerprints or resolvable identifiers like Decentralized Identifiers), evidence of which can be found with SIOP V2, an early stage draft on portable identities and DID SIOP. Because of this it becomes problematic for the browser to enforce directed identifiers as they would remove the ability for the RP to validate proof of control over the subject identifier via a supplied digital signature.

The requirement to facilitate data sharing arrangements that go beyond identity information is vital to see adoption in “open banking” or “data sharing” ecosystem.

All banks in the U.K, Australia and New Zealand support OpenID financial grade api profile to share identity tokens and support data sharing between RPs and OPs. The document mentions this problem but doesn’t protest a solution. Can elements of the rich authorisation request be adopted to support granular data sharing arrangements.

In the example with fenced frames and permissions, it appears that before user interaction the IDP frame has some mechanism to communicate 1 bit of information indicating whether the frame should be shown or not (presumably the IDP popup needs to be hidden by the RP if no account is available).

Since these frames have access to first-party cookies, it seems that the RP in cooperation with a tracking "IDP" could do this:

<fencedframe src="//tracker.example/0.wbn"></fencedframe>
<fencedframe src="//tracker.example/1.wbn"></fencedframe>
...
<fencedframe src="//tracker.example/63.wbn"></fencedframe>

and then use the show/hide signal on each to extract 1 bit of information, extended in this way to an arbitrarily large identifier without user interaction.

Even if this is limited to one per origin, using same-site origins (which can share site cookies) or a sufficient set of coordinating domains could potentially create a unique trackable identifier.

cookies.md uses .well-known URLs ending in .php. Well-known URLs shouldn't assume a particular server-side technology like PHP. In this case they should probably be extensionless.

The provisioning stage mentions that the browser doesn't unveil who the RP is yet, but that the IdP already provides a sharded email ("email": "[email protected]"). That email is then shown in the consent stage mock. But, short of standardizing some deterministic function to go from canonical to sharded email for the browser to compute, this value cannot actually be produced by this stage.

The sharded email can probably just be removed from the provisioning stage and left to just the real one. (I see that's in the mock, but not the sample response. Was the idea that the response contains both?) We only need the information that would be shown in the consent prompt, but showing "[email protected]" in the consent prompt doesn't actually tell the user much. The sharded email is not recognizable or recitable, and the important point is that the email forwards to their real one.

For comparison, I see Apple's email hiding feature says "Hide My Email; Forward to [email]" in the prompt.

Immediate concern

In the Mediation API, there’s a "magic moment" where the browser knows which identity should be used for the sign in. Expanding the detail there to explain how the browser knows that identity helps us understand the implications there and what role and information the IdP plays in helping with that discovery.

Room for improvement

With the expanded detail above, it gives a jumping off point to discuss handling multiple identities that an IdP may have in session at the same time. Browsers could offer an account selector for IdPs, potentially replacing some of the IdP sign in functionality that relies on 3p cookies today (issue #34). Partitioning identities by session, such that there is only 0 or 1 identity for a given IdP in session, is not desirable as multi-account scenarios do exist (usually in the form of IdPs serving both consumer and enterprise users, example: offering a merged calendar or task view).

Suggested addition

On top of the active session discovery suggestion, support the ability to pass multiple identities from an IdP to the application in a single sign-in flow. This presents improvement over the single-user limitations of OIDC, and paves the road towards more fragmented, user-owned identity stories.

Related issues: #13

Other than functional and privacy related questions, security related aspects of a new Identity API are of paramount importance for IDPs. The IETF and OpenID Foundation have extensive security threat models and best practices documentation for the related core protocols, which are continuously extended. Latest relevant ones seem to be:

• OAuth 2.0 for Browser-Based Apps
• OAuth 2.0 Security Best Current Practice

Given the large majority of IDPs are based on OAuth 2.0/OpenID connect and would need to work with a sort of adapted browser client type, has there been any assessment yet on how WebID would impact the above? Given WebID would quite substantially change the flows that seems to need careful consideration.

I wonder if this explainer could expand more on the rationale for using a tab-modal dialog or the modal-window proposal instead of a top-level navigation, new tab, etc. Maybe some of the reasoning is similar to Payment Handlers, but I think it would be good to explain it here too and make sure that all the same reasoning still applies.

The new tab-modal pattern that's used for Payment Handlers is generally a little uncomfortable because it blurs the line between web content and native browser UI -- a line which is already fuzzy and not very well understood by users. Plus, the concept of showing two origins at once in the UI has been proven to be confusing to users in other settings (https://docs.google.com/document/d/1iaocsSuVrU11FFzZwy7EnJNOwxhAHMroWSOEERw5hO0/edit). On mobile in particular the bottom sheet pattern really gives up on the line of death concept (https://textslashplain.com/2017/01/14/the-line-of-death/).

All that to say, it's not obvious to me that it's a good idea to cement the bottom-sheet/tab-modal pattern for hosting arbitrary web content, so I think it deserves some more discussion in the explainer.

Here are a few things that comes to mind:

button personalization (e.g. profile picture)

For example:

And here is for google's sign-in:

auto sign-in

TODO(goto): gather links

Anything else we are forgetting? Anything in enterprise or EDU?

Users will have a prior relationship with any IdPs they can successfully use for federated authentication. Extending the concept introduced in issue #51, how about providing a mechanism for registering an IdP as a trusted redirect target in the browser, with user consent, hopefully at the time the user registers with the IdP? This could eliminate the need to analyse the APIs used with those IdPs, even APIs that are yet to be invented.

If we are transferring verifiable assertions from one party to another, we should do so via existing standardized signed assertion formats.

The most fitting format being the Verifiable Credentials data model: Verifiable Credentials Data Model 1.0 (w3.org)

Hi.
The feedback link led me here. There is a lot of prior work here that exists globally and want to highlight it to help inform and explore intersections with you.
I work at an organization that operates the Canadian Research and Education(R&E) federation. R&E is not one jurisdiction but a global activity and we participate in operating a global R&E community exchange point called eduGAIN spanning 68 countries. The R&E identity ecosystem and has 1000's of entities with around ~3,600 IdPs and ~2,900 Relying Parties. Foundation protocols are SAML based and you can see this at our public metadata exchange nexus at https://technical.edugain.org

Many of the topics being explored in webID are viscerally experienced by us having operated for over a decade. Our community of identity practitioners (IdP, RP, and Federation Operators) have acrued over a decade of experience and with the work in WebID I think there's some interesting opportunities to exchange thoughts and insight on your work.

Some are:

• The discovery/nascar challenge: Recent works like https://seamlessaccess.org and https://eduteams.org are recent activities augmented existing practices. There are others, but this is a somewhat solved area or known challenge that has been largely worked on.
• Scaling trust beyond SAML: The trust model in SAML affords many things but not all services implement well. We are also working on bringing the federation model to OIDC with federation profile work there thus leveraging OIDC infrastructure to carry additional trust
• Privacy: This is a core operational tenant in the R&E space and is manifest in many places both operationally and in policies too numerous to list and happy to discuss.

It would be interesting to understand how R&E federation does or does not address what is proposed with WebID as I think there's a lot we address. Thoughts welcome on this.

world

test

First off all thanks for pushing this topic forward, federated id/authorization are a key concepts for RP and user likewise going forward.. Ideating how they could be bundled with higher level capabilities of user-agents could be intriguing.

Having that said I think it would be good to scope the aim of the effort in a bit more depth in terms of how it relates flows / principals of OIDC Connect/OAuth 2.0 because they are the protocols of choice for any mayor IDP and coming from that angle this would allow us to slice and dice this much better. Since users interact via a multitude of devices types that are also not user agent based (native apps, SmartTVs, ....) generic protocols will need to work in conjunction with any new approaches / layers.

The explainer only generally differentiates between SDK and non SDK based approaches.

Confidential / Public Clients:

In terms of security IDPs typically differentiate between Confidential (server side/secure management of client authentication possible) and public clients (native apps, JS/SDK based integrations unable to do so). Based on the classification of the client they will:

• mandate certain Flow (OIDC) / Grant Types (OAuth) to prevent impersonation etc.
• restrict information sharing (claims), for example by only allowing mandatory fields in ID-Tokens etc.

Today one would categorise this sdk/user agent based approaches as public clients in term of holding credentials as well as in terms of API access (userInfo or any other), is the aim here also to establish

• user-agent side means of a confidential client by protecting the Sandboxed IDP (I guess thats tricky)
• or are you assuming the SDK will just wrap a PKCE type flow to allow a native/SPA type flow in a secure way (https://oauth.net/2/pkce/)

Todays SDK based approaches typically would still redirect to RPs server side once an authentication was established to actually use authorised APIs / store information server side. Assuming you'd want to avoid this, any thought on that?

Information Transfer/Access

OIDC/OAuth is mainly designed to:

1. Authenticate users to RPs (leveraging ID-Tokens -> OIDC only)
2. Authorize transfer of user information (OIDC) or more generically allow API access (OAuth) using access/refresh tokens for server side data transfer

Should this new API deal with Authentication and Authorisation (it seems so). What would be the high level flow of information look like, compared to how it's done today? The explainer mainly refers to ID Tokens, any thoughts on access tokens yet?

IDP vs. User-Agent privacy - cf. Friction

The main benefit / aim of IDPs is to decouple

• a users account (authorisation/ID mechanism) from an RP / specific user agent
• managing authorisations for an individual user for a specific RP (APIs, User-Data, Login behavior, ...)

The explainer explicitly aims to not introduce additional friction for a user, conceptually that would entail that the user can also retain choices with this API across user-agents / devices using the IDP. How will this approach allow a user to preserve "settings" with an IDP?

OAuth and OIDC are both available and useful outside of web browsing context. For example native apps (mobile or desktop) can use these flows to authenticate the user.

While permission-oriented and mediation-oriented variations are probably only meaningful in the context of the browser but the delegation-oriented variation seems particularly useful and applicable outside browser.

In particular the ability for IDP to delegate its token minting to another party (in this case browser) can easily be made generalized such that other user clients (e.g., the operating system) can play that role. I argue that delegation-oriented variation would benefit from this expansion of supported clients because it means that with more clients supporting WebID then user can sign in to their accounts in more places while maintaining IDP blindness.

If we accept that certain formulations of WebID are meaningful outside of the browser then this may have implication in the API design. For example one such implication may be that we would prefer the Browser <-> IDP interactions to be specified in terms of HTTP request/response as opposed to Javascript based callbacks. Any other implications?

privacy_threat_model.md has a broken link to the explainer

Hi, I've tried to test out the API in Chrome 89 (running version 89.0.4356.0) as per the how to guide and I've encountered an issue where I am getting this DOMException "Error loading the identity provider". Here is the little POC I was running to test, I can see the browser is making the request to the well-known endpoint but it then throws this exception before rendering any native UI, obviously the implementation of the IDP is incomplete but I cannot see why it would be throwing this exception.

It sounds like there is some step that the browser is supposed to do to get the user's consent to share the user's IDP identity with the RDP. But it's unclear to me where that step is happening or what it might look like. I know that different browsers might want to design this UX differently, but perhaps you could sketch out some ideas of what this might look like to help readers visualize the full flow.

Device authentication must remain at parity, but could be improved

A popular feature of enterprise IdPs is the ability to ensure that users are accessing content from corporate managed devices, that are compliant with customized policies. This compliance signal is generally passed to the IdP via a browser extension, client certificate, or the browser itself, and originates from other native components on the device (an MDM client, usually).

From a security POV it makes sense that extensions would be unable to hook traffic that is part of WebID sign-in – it is by-definition sensitive data being passed. If extensions are not blocked, then the existing methods of injecting device compliance and SSO state via extension can continue. It is not clear, but is expected, that client certificate auth would still work under WebID, and would have to be the fallback if extensions were no longer functional in WebID.

Opportunity to improve

WebID seems opportune to standardize an MDM interface for browsers to seamlessly get and pass along device compliance and SSO state. Today, IdPs must build custom solutions (usually extensions, if they don’t own the browser) per browser and per OS. The net result is best-in-class support in browsers owned by the IdP where first party integrations makes this work seamlessly, and support that grows weaker and less user-friendly according to the popularity of the browser and the extensibility points between the browser and OS. This hurts user choice in browsers and the easy spread of browsers within enterprises; enterprises will not allow the use of browsers that cannot prove device compliance. Furthermore, it reduces enterprise support costs when device compliance UX is lower-friction – avoiding support desk calls discussing certificate auth in a CredMan prompt is desirable. Standardizing this managed device compliance pattern allows IdPs to seamlessly support all browsers without making per-browser investments. This in turn removes one blocker from enterprise admins: allowing browsers like Firefox on their devices.

Privacy tension

It is worth calling out that device authentication is a cross-site tracking vector, as its function is to uniquely identify the device to the IdP. Users may need to indicate that they want their device state to be known to the IdP as part of the WebID flow, based on a request from the RP or (more often) the IdP.

Device + web SSO solutions

Devices generally can carry user identities as well - Apple, Google, Samsung, and Microsoft all have device-bound identities, often available to native applications, and support account brokers for third party identities. The extension and browser device authentication methods described above are also used to carry that device-bound identity to the browser, functioning as a stronger login credential than a password. This is used across both enterprise and consumer scenarios.

Mobile browsers often suffer from a lack of "device to web SSO" when the IdP and browser are not the same party. IdPs, browsers, and users would benefit from a standard interface for collecting SSO information from a broker on the device – better, more secure SSO for users, easier adoption for browsers, and wider browser support for IdPs.