1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. connect
  4. Issues

SIOP V2 dynamic iss claim ref: REQUIRED. Issuer. MUST be https://self-issued.me/v2

Issue #1208 resolved
Adam Lemmon created an issue

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)

  2. Michael Jones

    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?

  3. Adam Lemmon reporter

    Thanks Mike!

    We are primarily suggesting that in neither case should iss be constrained to self-issued.me

    But 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 the sub_jwk included within the token.

    Does that make sense?

    ‌

  4. Kristina Yasuda

    I think Mike is saying that if you put information about the SW provider in iss field, you can’t differentiate the cases when

    1. it is an end-user who used their own “self-issued keys“ to self-sign the ID Token
    2. it is an IdP who used user’s “self-issued keys“ to sign the ID Token

    ‌

  5. Kristina Yasuda

    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.

  7. Kristina Yasuda

    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

  9. Tom Jones

    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.

  10. ÜMÜT DUYUM

    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

  11. Tom Jones

    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?

  12. Tobias Looker

    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

  16. Kristina Yasuda

    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

  18. Log in to comment
Assignee
–
Type
enhancement
Priority
major
Status
resolved
Component
SIOP
Milestone
–
Version
–
Votes
0
Watchers
6
Jira Software: the preferred issue tracker for Bitbucket. Join the team!