Allow arbitrary SIOPv2 issuers (e.g. no openid:// authorization_endpoint limitation)

[David Waite]

SIOPv1 was defined to use a fixed issuer URI and custom policy with that URI, including a specific authorization endpoint. There are three reasons we should consider expanding this now to arbitrary URI:

1. The advent of Universal Links, which would allow a HTTPS URI to invoke a local native application
2. More complex use cases involving scenario-specific metadata and independent trust frameworks. This creates the need for distinct issuers.
3. The addition of OpenID Connect Federation and Automatic Client Registration, eliminating the requirement for some previously mandated custom processing rules (redirect_uri as client_id, inline registration metadata)

With SIOPv2, the expectation would be that an issuer can be a ‘SIOP’ issuer (representing any number of instances of native applications) by omitting the `jwks_uri`, which is a required parameter for non-SIOP issuers but makes little sense in SIOP. This would indicate that the id_token signing key does not represent the issuer but the underlying subject.

[Kristina Yasuda]

Is the proposal to omit jwks_uri in SIOP because several keys used by SIOP can be included in a file obtained by resolving a sub (ie DID Document or .well-known)?

SIOP issuer keys will still be identifier using sub, not sure what you mean by “arbitrary“ and by referency to “openid://“, which was an invocation method and was replaced by SIOP chooser mechanism.

[David Waite]

‌

SIOP issuer keys will still be identifier using sub, not sure what you mean by “arbitrary“ and by referency to “openid://“, which was an invocation method and was replaced by SIOP chooser mechanism.

SIOP v1 and v2 today are both limited to invocation with fixed issuers, which each have an authorization endpoint of “openid:” . This needs to change for us to be able to support invocation with other custom URI scheme and universal links/app links.

Another way of thinking about this proposal is to say that SIOP instances do not have issuer keys, they instead have subject keys.

Perhaps the strongest motivator is that this is a consistent and semantically understandable breaking change between SIOPv1/2 and regular OPs. It provides a switch that breaks OpenID Connect Discovery for all RP deployments not expecting SIOPv2 at the registration/metadata phase, and as such we should be able to reduce or concern about potential attacks during request/response processing between RPs that misinterpreted a SIOP instance as a traditional OP instance. For v1, the RPs already had a spec describing the fixed self-issued.me issuer value as a singlar/fixed value that you could reject.

Is the proposal to omit jwks_uri in SIOP because several keys used by SIOP can be included in a file obtained by resolving a sub (ie DID Document or .well-known)?

The proposal distinguishes a regular OP (which makes authoritative statements on behalf of many End-users) and a Self-Issued OP (which has no authority and may only represent one End-User) by the presence/absence of the issuer jwks_uri. This works because the issuer keys are not used to sign/encrypt id_token values - rather the subject key is. A SIOP instance also would not be able to protect common private key material across all deployments.

The limitation for this approach would be if you had a hybrid infrastructure for SIOP operation with some hosted components, say those supporting dynamic client registration or PAR as examples. However, both of these (and all other OP valid endpoints I can think of) do not leverage jwks_uri or return/issue JWTs.

OpenID Connect Discovery defines jwks_uri as a mandatory field, but this was changed in RFC 8414 .

Finally, it is what SIOPv1 effectively did as well: https://self-issued.me/.well-known/openid-configuration

‌

[David Waite]

See also: #1212, #1241, #1240, #1208, #1196

[David W Chadwick]

Why does the SIOP need any keys when VPs are being transferred, and the VP is signed by the subject’s key held in the wallet? The only thing the RP needs to be concerned about is that the VP it has received has not been replayed by a different user device/SIOP and is coming from the device to which the VCs were originally issued.

I really would like to understand the trust model that underlies the SIOPv2?VP model that people are assuming without articulating. In my opinion no software on the user’s device can be trusted by the RP.

[David Waite]

In my opinion no software on the user’s device can be trusted by the RP.

This is not an achievable trust model unless you decide never to interact with users.

[David W Chadwick]

We believe that direct anonymous attestation of devices will allow RPs to interact with user devices that have been attested to, and then RPs can trust them.

But what is the trust model that you have in mind?

[Jeremie Miller]

Why does the SIOP need any keys when VPs are being transferred, and the VP is signed by the subject’s key held in the wallet?

I think there might be two different trust model approaches that haven’t been explicitly called out:

1. The key signing the SIOP id_token is the same as the VP-signing subject wallet key.
2. The VP key/signing is completely independent from any used in SIOP.

I am, as I believe you are, of the mindset in #2 and also agree that the SIOP token-signing key isn’t useful or relevant to an RP who’s only interested in VPs.

I am quite sure there are others that believe the SIOP token-signing key is for exactly the same purpose as a regular OP, such that the RP can store and trust/auth against that key in future RP/SIOP interactions. And this is exactly what DID Auth intends to use SIOP for/as, SIOP as an HTTP mechanism to auth a DID-based subject.

And I believe that is part of what DW is trying to navigate both in this issue and the larger resolvable identifiers PR, is there a clean and simple definition of SIOP that supports both usage models.

‌

[David W Chadwick]

I am, as I believe you are, of the mindset in #2 

Agreed. This is why I asked DW to state his trust model. Without it being explicitly stated, then if people have different trust assumptions they will talk at cross purposes and develop mechanisms that are not needed for one trust model but are needed for another one.

I am quite sure there are others that believe the SIOP token-signing key is for exactly the same purpose as a regular OP, 

Yes, we discussed this on last week’s call. On the initial communications between the SIOP/Wallet and the RP there is little difference between the two models as the VP/VCs identify the user. But on subsequent calls, the regular OP model simply sends the id_token to identify the user, whereas in the VC case, the SIOP/Wallet sends exactly the same VP/VCs that it sent the first time. So this simplifies the SIOP/Wallet as it does not need to differentiate between first time and subsequent times. And the verifier/RP can either treat each call as someone new each time (if no account is needed), or it can look in its account database to see if the VP/VCs uniquely identify an existing user (since they must have done first time around for the registration to work and the account to be created). Typically the VC might contain a unique ID anyway (such as email address) that the RP can use as the identifier. But the neat thing is that it need not. So a barber could have separate accounts for different hair colours, and anyone with blonde hair would access the blonde hair account. ie. it makes creating group accounts trivial, since accounts are now based on identities and not on identifiers.

‌

[Kristina Yasuda]

this has been addressed in PR #54 that we merged last week. I suggest we close this issue unless there are specific concern regarding the points below:

• openid-fed automatic registration is not used since dynamic discovery or out-of-band mechanism should be enough for SIOP metadata as opposed to the RP metadata.

• not using jwks_uri is a very subtle flag that it is SIOP. I suggest we use iss=self-issued.me when static SIOP metadata is used and add a claim i-am-siop to the ID Token when SIOP metadata has been obtained dynamically.

  • suggestion made in PR #68 - please review.

‌

[Kristina Yasuda]

2021-11-17 call agreed to close this issue when #68 gets merged

[Kristina Yasuda]

resolving since we removed openid:// limitation in SIOP ie claimed URLs are allowed.