Relationship Management

[Tom Jones]

The major point of the user name is the establish a name that is used to lookup the user object that is maintained by the relying party. While the user typically gets to establish this name, it must be a name that is unique in the RP. If that RP has a large number of users, the chance that a simple name will not be available. The result is that the RealWorld user will have ~100 user names after a few years. That is not manageable by the user’s memory. Historically the user also has a password as a access credential. Eliminating the password is the current goal. the user name does not appear to have an alternate solution at this time. While the password manager was developed to recover passwords. it appears that even without passwords the user name will continue to be a value that is not possible for user’s to recall for more than a small number of web sites. (Here we are using the term web site to imply an origin name as defined by the browser.)

Since the user name will be with us for the short term, the password manager will be as well. It is thus presumed that the password manager will continue to be required for any enduring relationship. The question now is what data must be stored in the RP to allow the reconnection of the RP to an OpenID provider. Hitherto that just been a url to a web endpoint. Often that could be inferred from the user name itself (eg [e-mail]) But if the OP is hosted by the user such a url may not be possible. It is those cases where a new method must be defined for reconnection to be possible.

Here is one proposal. We define a “universal link” that is owned by the user and known to the browser. We require that the browsers and/or the compute platform help the user create that link and prevent requests to change that link from being requested by any accept the holder of the platform. We require that neither the browser nor the compute platform try to take ownership of this link. We acknowledge that no crypto method can be bound to this link for the totality of the duration of the link. We acknowledge the problem that if a link is established on one platform, some attacker may try to register that same link on some other platform and the resolution of that attack must be defined.

As a side note, it is possible for a did method to meet these requirements, but none are known to me at this time that require this permanence over any extended period. The methods that come close use IPFS AFAIK. My own thought is that a GUID registered on a did method are most likely to fit the bill. This will always that a period of minuets to be assured of uniqueness. Getting back to the password manager, this could be entered as the user name or as the password, as seems best after review.

[David W Chadwick]

Tom you said “the user name does not appear to have an alternate solution at this time.” However, with VCs, there is an alternative solution. When the user first registers they present a set of VCs that uniquely identify them to the RP. The RP creates a new DB entry for this user (checking first of course that this entry does not already exist). When the user returns and selects login, the RP checks its DB for the entry that was created at registration time. In both cases the same set of VCs can be presented by the user to the RP. The only difference is that the user clicks on Register or Login when accessing the web site.

[Tom Jones]

the following is the hard part that i cannot see be addressed w/o a user name. It’s the basic blocker to siop. (re: the 1st sentence of the issue.)

“the RP checks its DB for the entry that was created at registration time. “

[David Waite]

Re: David

A VC should not be used for authentication unless the issuer has a statement that it can be used for such purposes.

The proof in the VP might be usable for such purposes if proofs can be determined to be based on equivalent cryptographic secrets or control of a common resource (e.g. same public key or same DID). An application has to balance this with a decision about how much they trust the key/DID to have appropriate controls in place for their authentication requirements.

[David Waite]

Re: Tom:

There is not necessarily a need for a username unless you need to challenge against a particular account or provide a handle for account recovery.

For SIOP, you can simply say “I want an id_token” and if you get one you recognize back, the user is in.

Even for account recovery, you could conceivably say “I want one of these VCs presented to me” and use document validity and providence along with some form of ID proofing to recover access.

Outside of user-specific challenges, the other reason sites ask for username first is because we have authentication methods which require user education, like FIDO 2, or which may always fail, like a “Login with SocialNetwork” button when the RP has no idea who you are on that Social network.

WRT browser managed data; custom password-manager-like web extensions are limited in some contexts (e.g. iOS) and unavailable in others (e.g. Chrome on Android). Assuming users will have a web extension installed in order for a website to function is widely considered to be a non-starter.

Also, web extensions typically only have the ability to directly talk to a single native application, so you wind up either exclusively using a single wallet, or have severe integration compromises (which result in UX compromises).

The upcoming approach is Credential Manager conditional mediation, where the browser will be able to query local state to see if a request “made to the void” by the RP via javascript is actually answerable, and presents the user the option to respond to that request. With this, there are proposals to have Web Authentication flows integrate with the same sorts of UX practices as password managers - Apple calls this PassKey.

‌

[Tom Jones]

Right! so help me out here - how does an RP say “I want an id_token” when i know nothing about the user that is not in the HTTP header (cookies cannot always be relied upon - so all the RP has is the UA string.) I am guessing you mean some sort of js call to an as yet undefined API?

BTW - if we can define the API and how it related to cred man today - i would be happy to file a CR bug or wicg proposal.

[David W Chadwick]

To DW who said “A VC should not be used for authentication unless the issuer has a statement that it can be used for such purposes.”

A VC can be used for whatever purposes the RP is willing to accept it for. The Issuer has no knowledge about how or when the VC is being used or who it is being sent to. In the VC model, the RP is its own root of trust and it is solely responsible for deciding which VCs to accept for which purposes (and can accept expired VCs if it wishes to). So if the user can DPOP the private key and sign the VP with this, and the public key is the subject ID in the VC, then the RP knows that

a) some user has proved possession of a private key

b) this same user has been identified by issuers that I trust, and the identity is bound to the corresponding public key.

Conclusion. I know the identity of some user and I know (s)he is controlling the public/private key pair associated with this identity

To Tom who said “I want an id_token”. I thought with SIOP we were moving to vp_tokens?

[David Waite]

Re: David, who said “A VC can be used for whatever purposes the RP is willing to accept it for.”

Sure, and people accept covid credentials and smart health cards without checking the name or asking for ID. There’s strong recommendations against those practices as well.

There’s no requirement that a VC have a subject. There’s no requirement that the VC be presented by the subject. And there’s no requirement that the issuer be trustworthy or that the RP has any recourse if the document, while signed by a trusted issuer, is fraudulent.

Accepting a VC is a id proofing risk decision involving unidirectional trust of third parties and your consumption of their documents. It is a risk decision every time you do so, especially when attempting unlinkability since you won’t recognize it as a VC you’ve seen previously.

Even with a VP and traditional signatures using persistent keys, you can’t actually use it out-of-the-box for authentication because there’s no protocol.

[David Waite]

Re: Tom

Today, you would have a button marked with some branding better than “Sign In with SIOP” and it would redirect the browser to say openid:// (at least today) . You either eventually get redirected back an id_token signed with a public key you recognize, an error, or the user is lost to the void.

We don’t get much more than this on the web platform, because we are sandboxed from seeing what applications are installed or getting hints about their persistent state.

Knowing anything about the user automatically is right out, because that would be tracking information for the taking.

An owned URI, whether be via LID, or OpenID with Yadis or XRI, or OpenID Connect with WebFinger, or a DID, really only serves to verify the URI has usable metadata behind it. Even if you redirect to Google or Microsoft as your OP, you either get back an id_token signed with a public key you recognize, an error, or the user is lost to the void.

I don’t know if by Universal Links you mean the Universal Links technology or are speaking of something more like a user-owned URL. Universal Links themselves are site metadata controlling whether a site is presented by default in Safari or an installed Native App. It is a build-time configuration setting in the native app, so it is not really usable for per-user URL identifiers except what that app is also associated with the domain of the URLs, such as say a social network’s user pages.

That the user supplying a URI does not buy much is one of the reasons that OpenIDs and XRIs (as user identifiers) didn’t make it - because many users couldn’t understand owning and managing their own identifiers, but they could understand leveraging one account to log in other places. So why not just have a set of buttons to delegate all of that UX to select OPs via federation?

[David W Chadwick]

To DW. You are right that the risk is all on the RP. So most (if not all) RPs will want to reduce their risk as much as possible. This can be done via joining federations, obtaining reliable meta-data, contracts with issuers, secure protocols etc. But ultimately the residual risk that cannot be mitigated by the RP will have to be absorbed as trust. This is why I said the RP is the root of trust and it ultimately makes the go/no-go decision to accept the user’s VPs. Our role should be to define SIOP and OIDC with VPs protocols with as low a risk profile to RPs as possible, without unduly constraining them.

[David Waite]

To DC: Right, my point isn’t that verifiers should not accept VPs, but that they should not (as RPs) rely on them being the same every time or accessible in the future. Instead RPs should be establishing their own local credentials using say SIOP id_tokens or WebAuthn or RP-issued VCs.

[David W Chadwick]

To DW. I agree with you. The RP is then fully in control. But, if the RP is relying on the Issuer’s VC in order to do something for the user e.g. the RP is an insurance company and the VC is a driving license, and the user wants to renew their insurance (and has to prove they are not disqualified from driving), then the RP may well rely on the VCs each time the user logs in, and may not issue its own token.

[Tom Jones]

AFAICT neither David is considering the user journey, which was my goal in this issue. Today the majority of users have a few sites that they trust and visit on a frequent basis. For very-high frequency sites cookies work within a single browser ecosystem. For either multi-browser or less frequent sites the user experience that i understand from their input, is essentially the same as that for the initial registration step, ie a NASCAR window. IMHO that will not be enjoyable to users and so not employed by any RP that depends on happy users that return often to their sites.

In my world the RP can always display a un/pw widow that triggers the password manager. This gives the RP a pair of data fields, one that is in plain text and one that is typically obscured, but discoverable by the user. My assertion is that this is far more than a hint to the RP but can by made sufficiently rich that the RP can initiate a sequence that results in a full sign-in process based on data stored in the user object maintained by the RP with no more NASCAR window.

[David W Chadwick]

Tom. I am encountering a number of frequently visited sites that now ask for my UN (email address) on page 1, and then my PW on page 2. I believe this user journey can be used by the RP that wants to cater for all different types of users (federated, SIOP, direct log in etc). Assuming each type of user has already registered by using their unique email address, then the RP can show a login window for the email address, and once it has captured this, can determine which authentication method to use for the user given the local data it has stored from the initial registration. So it the local table says local password, it will display a password box; if the local table says SIOP, it will send its policy for VCs; if the local table says federated via google, it can then redirect the user to google etc. Wont this work?

[Jeremie Miller]

It’s unfortunate that the email address has become the de-facto username, resulting in both a marketing pathway and globally correlatable identifier being the default choice for users.

Tool-assisted login flows (password managers, WebAuthn, etc) are not always available for any given user so fallback mechanisms are required, which just reinforces the usage of the email address.

In a future with VC/VP-capable tooling widely available, then they could serve as a superior recovery method even when the user has switched devices/platforms/wallets. The drawback being, if that method is combined with privacy there would not be any identifier in the VP to associate with the original account at the RP. And as Tom suggests, a user can’t be expected to create and remember all their usernames, nor would there be any way for the RP to even verify it was the same user if the VP is by nature un-linkable.

Instead I would propose the use of a pseudonym for this purpose, one that is unique to each RP and can be cryptographically generated and proven by the subject’s wallet software. These can be created on-demand in that software with guarantees that they are unique and also never revealed to the VC issuer.

Unfortunately, the only ways that I know how to accomplish all of that is through the use of Zero-Knowledge Proofs. While ZKPs aren’t well accepted primitives yet, perhaps by the time “a future with VC/VP-capable tooling widely available” happens that will change and we could standardize on cryptographic recoverable private pseudonyms as a replacement for usernames and email addresses.

[Tom Jones]

Jeremie - creating the ID is not the issue. a guid for example works fine. The issue is attacks against such an ID. There are two places i know to guarantee uniqueness. The RP can do it for a RP specific user name. The IPFS (with a little help) can do it for the user unique ID. In each case the user has a delay before the uniqueness guarantee is complete, but that time be used for other purposes and will really only fail for attacks, or blundering. Note that you can get the same effect with an email service that is not really used for email, or only used for notifications, which would be a good thing IMHO.

[David W Chadwick]

Jeremie you said “The drawback being, if that (VP/VC) method is combined with privacy there would not be any identifier in the VP to associate with the original account at the RP.” This does not have to be the case. Remember that the RP is in control of the initial registration and will send its VC requirements to the user’s wallet. If the RP’s policy is to require a subject attribute that it knows is a unique identifier (e.g. SSN, passport number, mDL number, even email address!) then it is irrelevant what the subject’s ID is and this can be ephemeral and change every time, because the trusted issuer is stating what the unique identifier of the subject is, as a subject property.

[Jeremie Miller]

Jeremie you said “The drawback being, if that (VP/VC) method is combined with privacy there would not be any identifier in the VP to associate with the original account at the RP.” This does not have to be the case.

What I was trying to say by “combined with privacy” was to specify the exact case when the subject has chosen not to disclose any issuer-provided unique identifier.

By supporting an issuer-bound cryptographic pseudonym as an alternative, the RP can still satisfy any unique identifier requirements without having to violate the user’s privacy.

[Tom Jones]

None of these last messages seem to be related to this issue. If the user is browsing to an rp where a relationship exists, there is no wallet engagement yet. If an cookie exists there’s no problem. If there is no cookie what can the user say to the rp to reinitiate the connection? And remember, there is nothing the rp gets to ask about the user at this point.

To @jeremy, I would call that an alternative ID. It is otherwise indingusable from another I'd, unless perhaps it is flagged as an id that you don’t want tracked. Ie where any user object created by the rp would have limited life time. I prefer calling these session IDs.

[David Waite]

I’m going to attempt to go back to the original request

The major point of the user name is the establish a name that is used to lookup the user object that is maintained by the relying party. While the user typically gets to establish this name, it must be a name that is unique in the RP.

This is a requirement for a subset of relying parties who are trying to establish local named accounts. One popular reason for trying to establish a local named account is to support multiple local and remote authentication schemes for a single user, as well as to account for the potential need of local account recovery.

Since the user name will be with us for the short term, the password manager will be as well. It is thus presumed that the password manager will continue to be required for any enduring relationship. The question now is what data must be stored in the RP to allow the reconnection of the RP to an OpenID provider. Hitherto that just been a url to a web endpoint. Often that could be inferred from the user name itself (eg [e-mail]) But if the OP is hosted by the user such a url may not be possible. It is those cases where a new method must be defined for reconnection to be possible.

You cannot guarantee from an address that you will go to the same OP, especially a SIOP. A traditional OP is just far more likely - someone would have to substitute network infrastructure.

We haven’t even really decided what the “same SIOP” is. Another compliant native app? One that's part of the same trust framework? A particular product? A version of that product? A unique installation on a single device?

I think all of these could be the right answer, which to me implies a lot more platform-level smarts than an a persisted URL.

[Tom Jones]

Well, fantastic platform smarts is a nice dream. I guess I think oidf needs to articulate what those might look like. Relying on the browsers has not worked yet.

[Kristina Yasuda]

sounds like there are no specification text changes needed and the recommendation to an issue raised boils down to “There is not necessarily a need for a username” in SIOP. Holder’s key used to sign a Self-Issued ID Token is unique to a User.

Pending close - will close within a week unless there are objections.