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

Issuer Handling in SIOP

Issue #1400 resolved
Torsten Lodderstedt created an issue

The current revision of SIOP utilizes two ways to allow the RP to detect that an ID token was issued by a SIOP:

In case of static discovery, the static issuer URL “https://self-issued.me/v2“ is used for that purpose. In case of dynamic discovery, the i_am_siop claim is used to mark the ID token as self-issued (since the iss value is the actual issuer URL used to discover the SIOP).

I think this is more complex than it needs to be and does not use the “iss” claim to identify the issuer of the ID token. OIDC Core defines iss as "Issuer Identifier for the Issuer of the response". That feels natural to me and I think we can use the same concept in SIOP as well. Who is the issuer of the ID token in that case? It is the user.

So I propose to set the iss claim to the value of the sub claim in the same ID token in order to mark an ID token as self-issued. That is also inline with the way X.509 handles self-signed certificates (Subject and Issuer refer to the same DN) and the W3C verifiable credentials data model handles the iss value for JWT-based VPs (https://www.w3.org/TR/vc-data-model/#example-jwt-payload-of-a-jwt-based-verifiable-presentation-non-normative).

A RP would determine whether an ID token is self-issued by checking whether sub and iss contain the same value.

Comments (47)

  1. David W Chadwick

    This is eminently sensible. As you say, the W3C spec says “iss MUST represent the issuer property of a verifiable credential or the holder property of a verifiable presentation.” Since OIDC is returning a VP and the holder is the user, then iss will be the user’s ID

  2. Torsten Lodderstedt reporter

    The ID token is not strictly speaking a VP but I think the principles apply in case of SIOP.

  3. David Waite

    In case of static discovery, the static issuer URL “https://self-issued.me/v2“ is used for that purpose. In case of dynamic discovery, the i_am_siop claim is used to mark the ID token as self-issued (since the iss value is the actual issuer URL used to discover the SIOP).

    This is not how this should work. SIOP id_tokens should always contain i_am_siop. The https://self-issued.me/v2 should merely be a narrow compatibility base which SIOP implementations may support, providing a guarantee of authentication and basically no other guarantees of supported features.

    But I don’t expect existing OPs to figure out that the id_token is operating under a different model based on knowing all the world’s static issuer URLs. I expect them to know either by not having the issuer on its static allowed list, by resolving the metadata of the issuer and seeing that it does not have a JWKS URI (and thus has no ability to sign), or by noticing the i_am_siop claim.

    To put it differently, supplying jwks_uri in metadata tells you that an implementation is not SIOP. i_am_siop in the token tells you it is.

    So I propose to set the iss claim to the value of the sub claim in the same ID token in order to mark an ID token as self-issued. That is also inline with the way X.509 handles self-signed certificates (Subject and Issuer refer to the same DN)

    We have a split between the identity of the AS (e.g. an implementation of https://self-issued.me/v2 ) and the identity of the end user, so we need both to be supplied in claims. The SIOP issuer may indicate say a vertical deployment (healthcare wallet) or interoperability profile that the SIOP is expected to operate under, so the value itself is still important. That doesn’t mean it needs to be in the iss claim, but I would want it in the JWT someplace or language mandating the subject is bound pairwise to the requested issuer and the client_id.

    That said, the sub claim may be substantial, including multiple crypto keys in the case of some DID methods. Even if it is just a thumbprint you are guaranteed this will increase message size over the use of most issuer URLs.

    One could argue that the fact that sub != iss is most of the reason SIOP exists. If sub = iss, then it is a normal id_token; you just have to have new logic to know how to process the iss value when it is a DID or thumbprint.

  4. Torsten Lodderstedt reporter

    That doesn’t mean it needs to be in the iss claim, but I would want it in the JWT someplace…

    I would like to have that as well. It could be another signed element (more as kind of attestation).

  5. Stephane Durand

    I have two cases in mind that make me think we shouldn’t be too fast tying the issand subto the same value:

    1. sub and iss do not represent the same facet of me.

      • The subject is me, as I want to be identified by the relying party (maybe I have an official id, maybe I have an ephemeral id, a pairwise one…)
      • The issuer is me also, has having a capacity to issue an id token, and this capacity can be revoked. For instance I have an Identity wallet on my mobile phone and I lost it, then I will take steps to revoke this identity wallet (which implements my capacity to issue some id tokens) but I may want to leave the validity of the identifier I used in the sub untouched.

    2. Another case is that as guardian of my kids, I might need to be able to issue id tokens for them (much like they have their own passport but the signature on it is mine), so the sub would point to my kid and the iss to me.

    ‌

  6. Torsten Lodderstedt reporter

    @Stephane Durand: Can you please explain how you would implement your use cases with the current SOP v2 draft?

  7. Stephane Durand

    I cannot obviously, but I suppose you knew before asking 🙂

    My point was not to defend the status quo but to raise a concern about binding sub and iss together. The more important question in my opinion is whether the cases I presented (or others) are considered relevant.

    Assuming so, this should be another issue to raise with the current draft.

    Back to your issue (and likely the others you posted around the same time, if that’s not off topic), I understand your observations as:

    • The writing of the draft has been done under the bias that the SOP is implemented as a mobile app: retrospectively, I fully agree and I am in line when you point that this shouldn’t be the case.
    • On that premise, it’s completely fair to re-ask what makes SOP different from regular OP,
    • and I suppose you came up with different answers for the respective points of interactions with the SOP; in the present issue, on how to handle a SOP-issued id token.

    So, to clarify, my concern is not about changing what the draft has put in iss, but rather to say that it must be the same as sub.

    Am I correct in guessing that you would welcome an uniform way to handle the id token, where iss can be used to retrieve the signature verification material of the issuer? If so, I kind of recall that a concern was expressed that a SOP-issued token could be mistook for one from a regular OP (with potential trust model implications) and having iss defined this way prevented this to happen (just reporting, I don’t have a strong opinion on this).

    If this SOP vs regular OP id token detection is not really an issue, then I subscribe to having the issuer identity referenced in iss (which could be the same as the sub in most cases and a different one in the few cases I shared before), and having i_am_siop being the way to indicate the SOP nature of the issuer (if that’s even necessary).

  8. Torsten Lodderstedt reporter

    My question was meant as open as I expressed it. I personally didn’t see a way to express what you were asking for with SIOP but I assumed I might have overlooked something. After spending some time re-considering it, I think your use case (1) can be solved with DIDs and use case (2) requires verifiable credentials in addition to the ID token.

    Here are my thoughts:

    SIOPs allows to establish trust in a public key or identifier by proving possession of the/a corresponding private key. Everything else is self-declared (except one incorporates assertions issued by trusted 3rd parties - I will come back to that). So the possible value range is pretty limited. Having differing dynamic values for iss and sub (e.g. me as issuer and one of my kids as sub) means one needs to decide which of those values will be cryptographically proven and which is self-declared.

    Use case (1) would fit into SIOP’s capabilities if one uses DIDs as identifier, since then the actual signature can be created using one of the keys associated with the DID. iss and sub would contain the DID and the kid in the JWT header would refer to the actual key. The iss value would represent "The subject is me, as I want to be identified by the relying party" and kid would contain the revocable identifier (the key id). So the actual key on your phone could be revoked (from the DID) if you loose your phone but you would retain access with the other keys assigned to you DID.

    For the second use case, I think, one could use a verifiable credential issued by a trusted issuer asserting you are entitled to act on behalf of your kid. But I’m not sure about the use case. If you would use a verifiable credential, the RP could request that within a SIOP request by utilizing OIDC4VP syntax and the SIOP could then provide a verified presentation in the vp_token response parameter.

    Back to the issuer topic: yes, I’m looking for a uniform way of issuer handling, i.e. as less deviation as possible from OIDC Core while ensuring the robustness and security of the process. Setting the iss value to the sub basically follows the OIDC Core’s philosophy of denoting the “Issuer Identifier for the Issuer of the response“. That would also mean we could stick to the logic that the effective user id is built by combining iss and sub 😉

    There will, however, be some differences in key resolution, e.g. jwk_uri vs sub_jwk, and discovery & validation, e.g. issuer in the openid-configuration vs iss value in the ID token. I think the simple equality check between iss and sub will suffice to determine for a RP which way to go in the validation and processing of the response.

  9. Stephane Durand

    My question was meant as open as I expressed it.

    Sorry, I didn’t mean to sound sarcastic but I actually didn’t look into how to implement the use cases before you asked and considering how quickly I came to the conclusion that the current draft would not let me use iss in particular as freely as I was suggesting in the use cases, I took your question as a way to giving me the face to figure it on my own.

    SIOPs allows to establish trust in a public key or identifier by proving possession of the/a corresponding private key. Everything else is self-declared […]. Having differing dynamic values for iss and sub (e.g. me as issuer and one of my kids as sub) means one needs to decide which of those values will be cryptographically proven and which is self-declared.

    I can’t find a fault with that, but it kind of does feel incomplete though. And maybe that’s because we are not having the trust model in the picture. Let me throw a possible mapping of EU Id Wallet into the discussion (even though at this stage of the eIDAS expert group, this is mostly speculations) to help putting names on the ideas.

    • My EU Id Wallet is a SOP. It was issued to me on the basis of

      1. It is functionally and security-wise certified to fulfill functions related to my identification (a verifiable capacity assertion)
      2. Both my identity has been identified and the wallet capacity mentioned in a. has been verified prior to deliver some information about me into the wallet. Information includes a unique and persistent identifier, let’s call it EuId.
      3. After b, only certified wallets with which I submitted my identity for verification can hold this EuId.

    • The sub here will be this EuId. It is self-asserted in the SOP perspective, but considering the surrounding eIDAS trust model, it was actually assigned to me by another authority. (Alternatively, sub could be my kid's EuId as well, provided I proved my guardian status in addition to identity verification during provisioning).

    • The iss is "me consenting to disclose my identity" in the perspective of SOP. With the eIDAS trust model, it is still that, since the consent remains important, but it is also, indirectly, the fact that the wallet is certified and this is rather where the trust comes from. I envision that cryptographically, iss is related to my wallet and rooted in both the wallet capacity assertion and the fact (a reference to) that I went through identity verification.

    ‌

    The approach you proposed with DID works technically but I think SOP / Core have better value as solution design option when reliance on external techno remains minimal to implement use cases (This doesn’t of course prevent them to also be able to implement use cases in conjunction with some given external techno.). For example, wouldn’t using DID as form of EuId imply to publish it in a public registry and wouldn’t that trigger to address further considerations about the privacy implications?

    ‌

    For the second use case, one issue I might see with the use of VC is that the VC should probably be returned as fulfillment of a specific requirement in a PE definition of equivalent (? or the VC attesting of my guardianship over my kids could spontaneously be offered in way of proof to legitimate me answering for my kid’s id request? ). This may be fine (or not?) if the RP made the request as vp_token or id_token defined as relying on vp, but without context, I assume that a RP would rather request an openid scope.

    Also, still thinking about EU Id Wallet, it is expected to be accepted by many relying parties for identifying their users. While VCs will be great to support identity/”credentials” sharing with relying parties use cases, I think that being able to implement the identification use case on OIDC only would make it easier for relying parties to reach that acceptance (be it only because this is already the technical base for several social logins) and increase the overall reach of a SOP EU Id Wallet.

  10. Kristina Yasuda

    I support iss = sub as “a uniform way of issuer handling in SIOP“. Non-SIOP ID Token tells the RP “this is how this OP (iss) identifies the user (sub)". Since in SIOP ID Token, user is “self-identifying”, iss = sub makes a lot of sense.

    iss=self-issued.me/v2 made a lot of sense, too, but now that we introduced dynamic SIOP discovery, I have already heard confusion around what to put in iss field, so iss= sub would also help interoperability.

    That doesn’t mean it needs to be in the iss claim, but I would want it in the JWT someplace…

    To enable portability of the identifier, I would want to avoid putting OP provider attestation information in the iss field. I changed SIOP provider, but still want to use a same sub identifier. Filed issue #1412. You can put information that the wallet is certified in the attestation claim that I hope we can define.

    Having differing values for iss and sub means one needs to decide which of those values will be cryptographically proven and which is self-declared.

    @Stephane Durand , In my opinion this use-case does not lead to iss and sub having to be different values. There may be two scenarios based on what you want to communicate to the RP: 1) parent’s identifier and tie claims about a kid to that identifier, or 2) kid’s identifier and a claim who is kid’s parent. Either way, ID Token would be signed by one key. This kind of scenario is why OIDC4VP does not mandate ID Token sub to be equal of a VC sub .

    have an Identity wallet on my mobile phone and I lost it, then I will take steps to revoke this identity wallet but I may want to leave the validity of the identifier I used in the sub untouched

    Relevant issue #1381. As Torsten pointed out this issue is solved when DID is an identifier, but if sub is a JWK thumbprint whose private key is bound to a HW, I don’t think there is a way to enable this scenario.

    Since OIDC is returning a VP and the holder is the user, then iss will be the user’s ID

    @David Chadwick, I think it’s not the first time you interpret the conversation about an ID Token to be about a VP. ID Token is mandatory in SIOP, while VP is not…

    ‌

  11. Torsten Lodderstedt reporter

    @Stephane Durand

    I agree with Kristina, in that I would like to keep the key proof and attestation of the wallet (software/service provider) distinct from each other.

    I’m not sure whether the EU Id will be a sub value. Is there a concrete technical design available yet? I assume the EU Id will more likely be a kind of base credential asserting personal data, as this is already the case for the so-called “base id” in the German ID Wallet project.

    Regarding DIDs: you are right, key rotation with DIDs will require public DIDs. I’m not a big fan of those DIDs because of the technical complexity and the privacy implications. However, sub values and key rotation, in my opinion, will require such public DIDs.

  12. Stephane Durand

    I agree with Kristina, in that I would like to keep the key proof and attestation of the wallet (software/service provider) distinct from each other.

    I also do, so my earlier comments may have been misunderstood. The key proof does need to be specific to a given instance of wallet, but in term of trust model, the legitimacy for the wallet to “represent” the holder is rooted in the fact that it has been associated to the holder (identity verification during provisioning) in a way that is verifiable (the wallet, as software/service version, attestation). So, for a relying party to be able to assert that this iss can be trusted to sign on behalf of the holder, there somehow needs to be a link between the key proof and the attestation (PKI or whatever equivalent).

    I’m not sure whether the EU Id will be a sub value. Is there a concrete technical design available yet?

    I’m don’t know either and not aware of technical output either. The work is currently happening behind closed doors within a group of expert mandated by the member states. That’s why I said my example was very speculative.

    However, how it is introduced in the proposed regulation amendment makes me think it could well be a sub in some cases:

    (…) unique and persistent identifier in conformity with Union law, to identify the user upon their request in those cases where identification of the user is required by law

    This is really a new item, that will be included in the existing “Person Identification Data” core id set (name, first name, DoB…).

  13. David W Chadwick

    @kristina The reason I am bringing the conversation around to VPs each time is the following.

    We already have SIOP (v1) which deals with SIOP pre the introduction of VCs and VPs i.e. without relying on a third party provider. I thought that we were introducing SIOPv2 to deal with the transfer of VPs and VCs (or other digitally signed credentials such as mDL from a third party provider) from the wallet to the RP. If not, then what is the scope of SIOPv2? To my mind SIOPv1’s scope should be “without a third party provider” and SIOPv2 should be “with a third party provider” as per my diagram here

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

  14. Kristina Yasuda

    @David, that is not the scope of SIOP v2. As discussion in issue #1399 highlights, SIOP v2 deals with “a trust model where the user is in control of the key material“. The scope of transporting VCs as VPs has been explicitly separated into OIDC4VP draft. SIOP claims by default are self-asserted, while OIDC4VP allows to transport third-party (issuer) asserted claims, so two specifications work very well together, but SIOP v2 alone has nothing to do with VCs/VPs.

    In SIOP v2, sub=key1/key2 correspond to the sub in the ID Token, not the VC.

  15. David W Chadwick

    @Kristina Can you please tell me what is the difference then between SIOPv1 and v2? Thanks

  18. Michael Jones

    During the 31-Jan-22 working group call, Vittorio Bertocci wrote “it sounds like forcing those two values to be the same would constrain the range of possible scenarios, hence it would be interesting if we could list some of the combinations that would no longer be possible and have one-liners explaining why they aren't interesting“.

  23. Torsten Lodderstedt reporter

    Vittorio Bertocci wrote “it sounds like forcing those two values to be the same would constrain the range of possible scenarios, hence it would be interesting if we could list some of the combinations that would no longer be possible and have one-liners explaining why they aren't interesting“.

    The current text limits the iss value to “self-issued.me/v2“ in case of static discovery and the discovered issuer URL in case of dynamic discovery. The only limitation of the proposed change is that the issuer value would no longer turn up in a self-issued ID Token. But: in contrast to 3rd party OPs this issuer value comes without any attestation/proof, it is just self declared.

    If we need to identify the service/software/agent that created the ID token on behalf of the user, I suggest to add another attestation element to the ID token. See also the discussion with DW about this.

  25. Kristina Yasuda

    Linking to Issue #1412 regarding Torsten’s comment on adding “another attestation element to the ID token“.

    Per discussion above, I don’t think SIOP provider information should be put in the iss, as it requires a separate proof/signature that the ID Token signature linked to iss/sub. so in the SIOP case, reproducing "multiple Google Accounts" experience will be different from the current multiple sub under the same iss ; it will be more like multiple sub (= iss) under the same attestation claim that we should introduce. I don’t know how the UX would look like tho - probably something like “multiple BYOI accounts provided by <SIOP wallet provider name>“ .. (all given I understood discussion during the 31-Jan-22 working group call correctly)

  26. David Waite

    The current text limits the iss value to “self-issued.me/v2“ in case of static discovery and the discovered issuer URL in case of dynamic discovery.

    This seems incorrect - the iss value should always be the issuer name, which is the URL for dynamic discovery and the URL or name value for pre-established relationships.

    The self-issued.me/v2 is just a baseline profile usable for authentication. It does not provide any guarantees of additional features or of operational policy. The dynamic discovered issuers are meant to provide those guarantees.

    The only limitation of the proposed change is that the issuer value would no longer turn up in a self-issued ID Token.   But: in contrast to 3rd party OPs this issuer value comes without any attestation/proof, it is just self declared.

    Our implementation wants this value in order to understand the metadata and thus the policy that was used for issuing the response tokens. This serves a different purpose than an attestation that the SIOP is a particular vendor implementation, running on particular hardware, etc.

    Again, this doesn’t necessarily need to be indicated via iss, but should still be captured in the id_token.

    ‌

  27. David Waite

    Per discussion above, I don’t think SIOP provider information should be put in the iss, as it requires a separate proof/signature that the ID Token signature linked to iss/sub

    This feels like a departure. My understanding is that an id_token is an asserted set of claims, and separate information (discovery, pre-existing relationships, federations, attestations, whatever) are a means of determining if those claims evaluate as trustworthy. If we delegate certain claims to instead be expressed through these avenues of evaluating trustworthiness, we create additional gaps and additional interoperability headaches.

  28. Torsten Lodderstedt reporter

    In traditional OpenID Connect, signer of an ID Token and the service producing the ID token is the same entity. And yes, there is attestation for the issuer URL, since there are rules to determine and to validate the relationship between the issuer and the ID Token (via key lookup and so on).

    In SIOP, the signer of the ID token and the entity creating the ID token are different entities. But we cannot convey both information in a single field. So we need to decide what goes into the iss claim and needs to go same place else.

    To me using the iss to indicate the entity that issued the token (from a conceptual/legal perspective) makes a lot of sense and is also inline with the ideas W3C & X.509 folks came up with.

    I would like to understand the gaps that are created. Can you please explain?

  29. David Waite

    The issuer for an OP is an identifier which represents several things:

    1. the target for requests (e.g. the aud of a JAR)
    2. the policy of what is supported for a request (supported authorization_endpoint, supported response modes, claims supported)
    3. cryptography and resolution (e.g. jwk_uri) to integrity check tokens

    4. the reputation of the party (including trust marks and brokered trust via OpenID Federation)

      1. other aspects of the RP relationship with the OP, such as policy around trust for stated claims

    SIOP obviously divides these responsibilities, as one or many pieces of software are acting on behalf of a particular issuer. And it sounds like we still aren’t operating on a common split of responsibilities under SIOP.

    The model I have been pushed for with SIOP v2 is that the issuer represents just a change in item 3 - e.g. beyond just a change in cryptography algorithms, that the way that you get the key for verification is different. You don’t use a jwk_uri in metadata, you look at the subject and resolve that.

    So for SIOP, the above list looks like:

    1. Requests are targeted at an issuer, which may be made up of several different implementations of software
    2. issuer values are either pre-registered or resolved to a set of common metadata, including the validation rules
    3. integrity is now done not by jwk_uri but by looking at and resolving the sub URI
    4. because the messages are signed by a more public entity, the reputation and policy for accepting information is different (hence the importance of VPs, e.g. claims made by other parties in a verifiable manner)

    Conceptually, trust marks and brokered trust via OpenID Federation would start to look like attestations, which a future spec may very well just bundle into a vp_token

    My issue with sub=iss is that it creates new SIOP-specific rules for signed requests and muddies the water for the issuer to be used to convey metadata. It makes the check for how to integrity check tokens and some baseline decisions around trust policy more explicit in the message structure, but the we already had ways to do this (such as i_am_siop). There is no requirement that we have parity with certificate self-signing rules, because id_tokens are not certificates.

  30. David Waite

    Note we have similar challenges with RPs as the above list for OPs. This is reflected in the difference between a public client and a confidential client.

    There have been many approaches to deal with trying to provide identity and metadata for public clients, from binding public keys to granted tokens, use of `id_token_hint` to grant a session to future authentication/authorization requests, dynamic client registration, and (in SIOP) the registration request parameter.

  31. Stephane Durand

    In SIOP, the signer of the ID token and the entity creating the ID token are different entities.

    Why does it have to be so?

  32. Torsten Lodderstedt reporter

    The signing entity is a user and the entity creating the ID token is is a piece of software.

  33. Torsten Lodderstedt reporter

    My issue with sub=iss is that it creates new SIOP-specific rules for signed requests and muddies the water for the issuer to be used to convey metadata.

    The rules for validating Self-issued ID Tokens have been different from traditional ID tokens from the beginning. I don’t see a big change here.

    There is no requirement that we have parity with certificate self-signing rules, because id_tokens are not certificates.

    Well, I have never seen any requirements list for what we do here. Beside that, I think it makes our life and the life of adopters easier to use already established concepts and patterns. The way issuers are handled in self-signed certs is well know and the same approach is used in verifiable presentations. If we need a way to convey self-asserted metadata or attestation (as already stated), let’s do it (in another PR). I think there are better and cleaner ways than bending the iss value for that purpose.

  34. Stephane Durand

    For me a piece of software is just a means and doesn’t need to be considered on its own. I don’t see where it separates from the one operating it; it certainly has no form of (legal) responsibility towards other OIDC parties.

    (Furthermore, I could argue that you can also split a regular OP as one piece of software on one hand and a (legally) responsible operator on the other hand. Let’s say I am a bank exposing an OIDC front running on premises; nevertheless, I rather likely took a license from an OP implementer than build it on my own.)

    Yet, I wouldn’t fully discard the notion of means in considering the issuer because it participates to the context of the token issuance. Context is not particularly relevant to the protocol but it might be to the trust framework with some means carrying more trust than others:

    • If I sign with my homegrown SIOP, it’s really me signing on my own and the relying party needs to have quite some trust in me
    • If I sign with a certified SIOP, whose activation involved strong IDV and whose signature carry legal meaning, it will be easier for the relying party
    • However, in both case, I am still the one signing; my decision, my consent, my word of honor.

    What is probably different with a regular OP, is that a given IDP will likely not run several OPs with different implementations… so the context matters less (it could actually, it just doesn't make much sense as a practical setup).

    A silly, yet existing analogy is that I am sometimes required to sign documents in colored ink… indicating that though it doesn’t change my identity as a signer, the means to make my signature does have an influence on the trust people have in it.

    iss sub trust model: liability trust model: assurance
    regOP IDP user IDP reputation of the IDP
    SIOP user + means user user reputation of the means

    If we have iss == sub, we lose either one of two things:

    • My (sub) identity will be tied to the SIOP I use. Maybe it’s acceptable, but it does feel like a limitation and as we are on the verge on an explosion in digital id usages, it would be a pity to miss opportunities for so little.

    • The SIOP I use is irrelevant, which has two impacts:

      • The trust level is aligned with the lowest of the reputation of existing SIOP implementation (that’s a quantity that converges to zero 😉 )
      • If my identity is breached once by one SIOP implementation, I cannot recover it. I need to get one reissued.

    ‌

  35. David W Chadwick

    @stephane. Identity is not the same as identifier. In your comment above when taking about sub, I believe that you should have used identifier rather than identity. So either:

    • My (sub) identifier will be tied to the SIOP I use. Maybe it’s acceptable, but it does feel like a limitation and as we are on the verge on an explosion in digital id usages, it would be a pity to miss opportunities for so little, or,

    • The SIOP I use is irrelevant, which has two impacts:

      • The trust level is aligned with the lowest of the reputation of existing SIOP implementation (that’s a quantity that converges to zero  )
      • If my identifier is breached once by one SIOP implementation, I cannot recover it. I need to get one reissued.

    The user has not lost their identity just because they have lost a computer generated identifier or this identifier has changed. These identifiers are freely and randomly generated, whereas the user’s identity is made up of a whole bunch of attributes gathered throughout their lifetime, and none of these will necessarily have changed. So the identity can easily be recovered. Consequently I would tend towards your second option, that the SIOP you use is irrelevant, the identifier you use is not that valuable (it can converge to zero) because your identity has not changed and you should be identified from your identity attributes. And these identity attributes can be asserted by trusted third parties (as in the OIDC4VP case).

  36. Stephane Durand

    “Identity is not the same as identifier” is a conceptual view (to which I subscribe) that may however be bound to real-world practicalities.

    Where the reliance on the identifier is really strong, even though it is but a projection of it, it becomes de facto the identity in the eyes of its user.

    I believe that can be considered to be the case in countries where you are assigned a number (social security number, citizen Id..) and that number is how you are known by administrations (In France, we get a such number from birth, and I haven’t heard that it could be changed through one’s life… ). Granted, your identity is larger that just such identifier and you can interact with other parties, but for these administrations, your identity overlaps with this identifier (and if you “lose” – “forget”, really – it, you can get it back – the same one, not a new one – from national DB after going through some IDV checks).

    In this discussion, I am not trying to paint the general model, just demonstrate that there are some specific cases that justify having different values for iss and sub.

  37. David W Chadwick

    But in SIOP we are not talking about social security identifiers or anything permanent like that. We are talking about a random public key id generated by the SIOP code. This is why it can be lost or changed almost at will by the user/SIOP code without affecting the user’s identity. The SS number OTOH I regard as an attribute of the user’s identity, that does not change. So if the ID Token is accompanied by a VP containing the SS number from the government issuer, then the RP can persistently and permanently identify the user regardless of the sub value in the SIOP ID Token

    P.s. It would be good to read my issue 1436 entitled Mental Models, because I think that part of the reason we have these long discussions is that we have different mental models that we are not articulating, and as my issue identifies, these models have conflicting use of the various OIDC parameters.

    Kind regards

    David.

  38. David W Chadwick

    @Stephane. It might be worth considering adding a third line to your trust table for SIOP+OIDC4VP because the RP’s trust now switches to the VC issuer. Here is the suggested entry

    SIOP+OIDC4VP user user VC Issuer “reputation of VC Issuer or certification of VC Issuer”

    ‌

  39. Kristina Yasuda

    because your identity has not changed and you should be identified from your identity attributes.

    @David, we have repeatedly stated, but identifying the user using user claims/attributes as opposed to an identifier within the issuer’s context (even if it is self-issued) is very dangerous and prone to attacks.

    ‌

  40. Kristina Yasuda

    @Stephane Durand Why do you think liability will fall on the user in SIOP model?

    Without attestation claim, we have very limited means to enforce what you called “trust model: assurance”, or even how to differentiate homegrown SIOP from a certified SIOP, especially if custom URL schema is used.

    ‌

  41. Stephane Durand

    But in SIOP we are not talking about social security identifiers or anything permanent like that. We are talking about a random public key id

    For iss, yes. So that applies to sub as well if we do the iss == sub mapping. But if sub and iss have different lives, I don’t see why the sub would have to be a crypto thing. On the contrary, I think it would be more helpful for RPs that it connects to something that’s potentially meaningful in the appropriate trust model.

    Why do you think liability will fall on the user in SIOP model?

    The user is the one making the conscious decision of signing the token, through their involvement in the iss ‘role’. So if the token is somehow fraudulent, I think the user’s responsibility is the first to be considered (and they would probably bear the burden of proving their good faith). I’m no legal expert, but this would make sense to me.

  42. David W Chadwick

    @Kristina. You are misrepresenting me by saying “identifying the user using user claims/attributes as opposed to an identifier within the issuer’s context (even if it is self-issued).” This has never been my position. Please let me (re)state my position clearly to you. The user’s identity is asserted to the RP by a third party that the RP trusts and not by a user’s claims or by a user’s self issued identifier. (Exceptionally the RP may accept user asserted claims, e.g. in a FIDO like exchange, but this is not the norm). In normal OIDC the TTP is the OP, in OIDC4VPs this is(are) the VC Issuer(s). If you are saying this is very dangerous then are you saying that every registration step in OIDC must be very dangerous, as must every re-authentication in SIOP with OIDC4VC? Because you appear to be saying that the trusted third party(ies) are not really trustworthy as the assertions they make may morph unreliably, or attackers can masquerade as the TTPs and dupe the RP.

    I think it would be good for us to both fully understand and appreciate each other’s position and iron out any misunderstandings or mis-representations.

    Kind regards

    David

  43. Torsten Lodderstedt reporter

    For iss, yes. So that applies to sub as well if we do the iss == sub mapping. But if sub and iss have different lives, I don’t see why the sub would have to be a crypto thing. On the contrary, I think it would be more helpful for RPs that it connects to something that’s potentially meaningful in the appropriate trust model.

    Can you please give an example? I’m trying to understand what meaningful different values could be that the RP also could put trust in.

  44. Stephane Durand

    I proposed mappings to projected EU Unique ID and social security numbers. I don’t understand in what way they don’t satisfy as example.

    Also, I expect that the RP will put its trust in iss and rather use the sub to identity/locate the user in its context.

  45. Kristina Yasuda

    During 2022-Feb-17 call, WG discussed that PR #120 has addressed actionable comments received up to date. Keeping discussion in PR #1400, WG decided to give people a week to review PR #120 and propose concrete changes if any.

    @David Waite @Stephane Durand @Vittorio Bertocci

  46. David Waite

    It was brought up separately that OIDC4IA and OIDC4VP have facilities which might be used for trust frameworks. I would comment that these are not normative dependencies, while OpenID Discovery and OpenID Federation are normative dependencies.

    Our reading of the spec today considers an issuer (such as self-issued/v2 ) to correspond to any number of SIOP implementations which have agreed to operate under the same operational metadata. 

    We expect that a signed request would have a `sub` of that issuer, that the redirection would be to that issuer’s authorization endpoint, and that the id_token indicates it was issued under that policy.

    This also better aligns with the id_token validation steps of Core (albeit due to the vagueness of "The Client MUST use the keys provided by the Issuer”), and with the definition of an issuer identifier in Core (which is defined to be a HTTPS scheme URI).

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