User with multiple devices

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1381

Original Reporter: dwc8

In OIDC it does not matter which device or browser the user uses, since the RP always redirects the user to the same OP, which always returns the same sub identifier. But with SIOP, the sub identifier is (the hash of) the public key of the user created by the SIOP on the device. So if a user has multiple devices they will have multiple key pairs, and therefore multiple sub identifiers. Can someone please explain how the user can authenticate with the same identifier from different devices using SIOP.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: peppelinux

I don't have an answer but a good chance to learn something. In “6.2.2. Dynamic Self-Issued OpenID Provider Discovery Metadata“ I read

subject_types_supported
REQUIRED. A JSON array of strings representing supported subject types. Valid values include pairwise and public.

subject_syntax_types_supported
REQUIRED. A JSON array of strings representing URI scheme identifiers and optionally method names of supported Subject Syntax Types defined in {#sub-syntax-type}. When Subject Syntax Type is JWK Thumbprint, valid value is urn:ietf:params:oauth:jwk-thumbprint defined in [jwk-thumbprint-uri]. When Subject Syntax Type is Decentralized Identifier, valid values MUST be a did: prefix follewd by a supported DID method without a : suffix. For example, support for the DID method with a method-name "example" would be represented by did:example. Support for all DID methods is indicated by sending did without any method-name. Note: need to confirm valid alg values that we want to explicitly support for id_token_signing_alg_values_supported and request_object_signing_alg_values_supported

having public subjects and a unique alg to hash them, well, it would be a weak kind of solution but I’d prefer to have in the subject value a resolvable DID.
At the same time a user would require to be uncorrelatable to RPs, when for example he releases a VP as anon creds.

It’s an important aspect that we may consider also in the UX experience field, when the user selects how to release his VPs

also mind that in a “traditional” multilateral federation we have many OP, the RP deal with many of them, continuosly, and also with users that authenticate in different time with different IDP.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tomcjones

This is really just a duplication of 1354 Relationship Management, 1380 and many others. The question has not been answered for SIOP. Unfortunately it does not seem to be answerable. It is certainly not the purview of any standards committee to solve your problem. If you cannot handle real-world problems, you will not succeed. If SIOP cannot work with real web sites, it will not be used. The issue, as it see it, has always been, and remains, how will the major browsers support the method.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

I do have a solution (which we have implemented) but so far the group has not been enamoured to it. Basically it is as follows:

1. the subject identifier is irrelevant, it can be transient
2. the subject/user is identified by identity attributes asserted by verifiable credential issuers that are trusted by the RP (these VC issuers do not reside on the user’s device)
3. these verifiable credentials are independent of the device that the user presents them from.
4. the RP decides which set of identity attributes it needs from which trusted issuers to uniquely identify each user in its context (the RP’s policy). This policy is provided to the user’s wallet via SIOP (e.g. as PE formatted construct)
5. the RP may create its own subject identifier for the user based on its required set of identity attributes, or it may create a compound DB key from the set of identity attributes.
6. in the former case, the RP has the option of becoming its own trusted issuer and returning the user a verifiable credential that it has created containing its own subject identifier. In this case the RP’s policy would ask the user for either the VC that it has issued or the set of identity attributes from the trusted issuers.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

Tom, regarding your last issue of how will browsers support it, in our current implementation the RP relays its request for VCs to the user’s wallet using scripts that are sent to the browser. I was hoping that we could replace the scripts with SIOP.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tomcjones

step 4 was addressed at the last meeting by more than one of the members.

IMHO it is illegal for the RP to tell the user to provide attributes that are not required for the transaction. (eu and california)

Attribute Authentication has been proven to the rather poor at distinguishing people.

As you can see from this link - attribute authentication would confuse Prince chas with ozzy osbourne. https://www.bbc.com/news/technology-37307829

I, for one, would vote against any standard that depended on attribute authn

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

identifiers are simply attributes that on their own uniquely identify the user. So it appears that you are against multi-attribute authn but not against single attribute authn. In which case could you subclass my design to replace “verifiable credentials from issuers” with “verifiable credential from issuer”, and “identity attributes” with “unique identity attribute” (ie. identifier). Would that work for you?

‌

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

David, what is your use-case?

WebAuthn/FIDO uses Device-bound private key per RP to identify a user, and it changes when the user changes the device, and it has worked and has been praised for the security offers.

The proposal to address an issue you describe which surfaced in certain scenarios has not been “subject identifier is irrelevant“ - it cannot be irrelevant since it opens up a big security hall. Rather a solution is to sync private keys across devices - it is called “Apple passkey“.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

The use case is a user with more than one mobile phone e.g. an iPhone and Android in which the keys are stored in hardware. So if the sub identifier is (the hash of) the public key then the user has two identifiers. You/Mike said the solution is to use software based keys and to sync them across devices, but I don’t see this is a solution to the problem. Rather a more elegant solution in the VC case, is for the trusted VC issuer to insert a unique subject id as an attribute in the VC, then whichever device presents the VC, the same sub identifier is obtained by the RP. And if the RP does not trust any external VC issuer to do this, then it can issue its own VCs to the user, containing just the subject identifier attribute.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

p.s. Apple Passkey stores the private keys in the cloud. But I believe it only works between Apple devices and not with Android.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tomcjones

Rather a more elegant solution in the VC case, is for the trusted VC issuer to insert a unique subject id as an attribute in the VC ===> I already have a few of those, they are called email addresses.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

There are also security considerations for this identifier which should be fulfilled (which email addresses and telephone numbers don't fully satisfy). Specifically

• immutable
• must not be re-assigned to another subject
• subject should be strongly authenticated before the VC is issued.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tomcjones

I think that you are confusing protocol syntax and governance or policy. There is no reason that email cannot satisfy those conditions, which have been discussed long before VCs were even articulated. None of these ideas has anything whatsoever to do with support of multiple devices. I have multiple devices and use the same authenticators on those devices already. I suspect you guys need to examine existing solutions first.

My understanding was that ION was sked to work on MSFT authenticator - can anyone get the current status of that?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

I think in SIOP case, when you making a choice to use a HW-bound key as a user identifier, you are making a choice for a user to have a separate identifier.

Having said that I understand this is not the best user experience and partially what has driven passkey.

passkey has a mechanism where user has two private keys - one that is synced, and one that is a HW-bound. Equivalent one in SIOP would be defining a second subject identifier - one that is HW-bound and a second one that can be common across devices. How to prove control of both, and prevent other claims being inserted is up to discussion.

btw, subject identifier is an ID Token claim. I am confused why you are talking about VC claims.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

@tom, ION is an overlay on Bitcoin, did:ion can be used by anyone, not just MSFT Authenticator

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

Given that ID Token is mandatory and VP token is not, I am now in favour of the VP being included in the ID Token since many of the fields are duplicated e.g. iss, sub, aud etc. We can then talk about VC claims in the ID Token that refer to the subject identifier. This will allow multiple devices to still use the same subject identifier using a VC property.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

I have drawn a diagram to show one possible solution to this issue. You can see the diagram here

https://drive.google.com/file/d/1R3kUk5Z1BcdaORTdOOQnayig430bS3UK/view?usp=sharing

This proposal allows the user to always be identified by the same subject identifier created by the OP/VC Issuer, regardless of how the user contacts the RP i.e. with a browser from a laptop, or with a VC from a wallet using SIOPv2 (where the keys are held in the hardware or software of the mobile phone).

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

I would need to think deeper, but attestation claim might help. same user identifier coming from different SIOP software.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: dwc8

Surely SIOP software is not as trustworthy as a VC Issuer? So the same identifier coming from the same VC Issuer by different routes is surely more preferable (from both a trustworthiness perspective and from a practical one, in that we already have the VC route and we dont have trustworthy SIOP software).

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: mbj

This was discussed during the 24-Feb-22 SIOP special topic call. People are encouraged to continue discussion on the issue.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

PR #515 - super simple text