- marked as enhancement
SIOP V2 dynamic iss claim ref: REQUIRED. Issuer. MUST be https://self-issued.me/v2
Hi all,
We have had some good discussions on this during past calls and I wanted to formally get this down somewhere to kick off a discussion and aim to reach consensus on the use of the iss
claim in SIOP v2.
We would like to discuss the option of enabling other URIs to be included as the iss
claim and it not be constrained to self-issued.me/v2.
For example being able to specify a URL of a PWA / cloud wallet provider as the iss
, which can prove useful information for an RP that is being presented claims from such. We’d like a model that does not presume a specific deployment architecture of a wallet but is inclusive; native, PWA, cloud, etc.
Also, we had previously mentioned that the presence of a sub_jwk
could be the signal to the RP that the token is self signed instead of the iss
claim being constrained to self-issued.me/v2, as one option to consider.
Look forward to the discussion on this topic, thanks!
Comments (17)
-
reporter -
In the usage you propose, would it be the issuer signing the ID Token in the normal way or are you thinking of using the self-issued key to sign the token, even though the self-issued provider is not the issuer of the token in this case?
-
reporter Thanks Mike!
We are primarily suggesting that in neither case should
iss
be constrained to self-issued.meBut I would say we are mainly referring to the self-issued model here. For example for a self signed ID Token
iss
could be the URL of a PWA and the token would be signed by thesub_jwk
included within the token.Does that make sense?
-
I think Mike is saying that if you put information about the SW provider in
iss
field, you can’t differentiate the cases when- it is an end-user who used their own “self-issued keys“ to self-sign the ID Token
- it is an IdP who used user’s “self-issued keys“ to sign the ID Token
-
Where should the information about “the provider of the SW used by the end-user as Self-Issued OP to self-sign an ID Token” is a good question.
How does the RP checks that it is a true SIOP SW provider and not a malicious provider pretending to be a good one?
In SIOP, RP being able to verify end-user’s subject identifier does not directly translate to trusting the SW the end-user is using. Having one signing key per SIOP provider is not secure and we can hardly expect each instance of SIOP provider generating separate signing keys.
-
The Kantara “Mobile Authentication Assurance Statement” is designed to provide that assurance. A trustregistry has been proposed to sign and hold the MAAS docs. https://trustregistry.org/
-
The issue was discussed on 2-25-2021 Atlantic call
- Why is there a need to communicate the information about the provider?
- In usual OIDC, semantic meaning of the issuer is authorization domain owner of the presented identifier, how do we translate that to truly self-issued environment?
- Three information points should not be confused: 1) which app, 2) which instance of the app, 3) who is operating that app?
- Semantics identifying a SW provider are closer to ‘client_id' than 'iss’
- This discussion is related to a higher level discussion on whether the issuer in SIOP is the SW used by the user or the subject identifier? Application itself does not have the identity - SIOP SW running on user A’s device is the same as a SW running on another device?
- Self-signed certificates could be looked as a reference - giving an option of including the same identifier as subject identifier and issuer
- Trust framework will also be needed for RP to be able to trust SIOP in addition to the protocol mechanisms
@Adam Lemmon
-
- changed component to SIOP
-
We need to look at the issue faced by the RP. They have no idea what the ID type is for a random user accessing their site. They can expose a “few' ID types, like “Google” and “FB” today, they are unlikely to exposed 90 DID types. Its not clear that the user would know in any case. So the question is how the user and RP negotiate to get to a mututally acceptable accommodation. Note that is never ok for an RP to ask the user to list all the ID types they have as the user may not chose to offer some of those to that RP. The best approach from the user’s perspective is to see a request for a identifier from an RP and select the one they have they they want to use with that site.
Note that we (Kantara an others) are working with US Healthcare to understand what a trust framework should look like.
-
Account Deleted Hello, if the number of computers or devices you use is more than one and you're only using one, you shouldn't remove other devices, but as a computer software expert and a developer, we can use both DOKU Sign and our own digital signature, so if you're a Novice for digital signatures or security, only one device, an E-mail, and a digital signature are enough. Sincerely
-
Not sure what this about anymore. It seems to confuse the native app and the PWA use cases. Perhaps we would be better served to talk about the information available to the RP code running in the user browser and how that is rendered into a meaningful choice for the user. So what choices are available for the user to chose from?
-
I would posit that even in a self issued environment there is still a provider, it is really the deployment of this provider that has changed e.g it takes the form of a PWA rather than a centralized HTTP server. Therefore the importance of identifying the provider remains unchanged as the existing OpenID trust model involves the RP trusting the provider not the End-User
-
- changed status to open
This has been discussed on 18-May-21 SIOP Special call.
Proposal was to have architectural deep-dive to discuss the scope of Self-Issued OpenID Provider specification.
http://lists.openid.net/pipermail/openid-specs-ab/2021-May/008338.html
-
This seems to be related to
#1196and so should probably be considered together. -
iss=self-issued.me being the main mechanism to distinguish SIOP flow from other OpenID Connect flows, I believe we should keep this.
-
I suggest we close this issue as it has been addressed in PR #54 that we merged last week. with iss=self-issued.me only when static SIOP metadata is used and iss=issued identifier when SIOP metadata has been obtained dynamically ie out-of-band or using OP discovery & .well-known/openid-config
how to determine that this is SIOP, is part of PR #68
-
- changed status to resolved
SIOP call 2021-11-18
- Log in to comment