For migration, should support multiple subjects at once in portable identifiers cases

Comments (20)

1. 

   David Waite reporter

   I believe the RISC group is looking at something similar, although for a separate use case (indicating the subject of events in multiple formats).

   • 2021-02-18T03:09:15+00:00
2. 

   David Waite reporter

   • edited description

   • 2021-02-18T03:12:46+00:00
3. 

   Tom Jones

   for better or for worse, the sub is often associated with a key that signs things. there is even a sub-key in some cases. I can’t imagine how multiple subs could be disambiguated for that.

   • 2021-02-18T06:01:40+00:00
4. 

   Kristina Yasuda

   Why do you say “using sub in this way precludes giving an actual public/pairwise identifier controlled by the OP”? Nothing prevents OP from issuing pairwise identifier per RP.

   • 2021-02-23T13:07:22+00:00
5. 

   David Waite reporter

   I meant that the OP would not be able to give a traditional sub controlled by the OP and a portable identifier (which is associated with the DID controller). Will edit content

   • 2021-02-23T22:52:57+00:00
6. 

   David Waite reporter

   • edited description

   • 2021-02-23T22:54:49+00:00
7. 

   David Waite reporter

   Kristina, changed bullet to read: “Using sub to represent a portable identifier such as a DID (associated with the DID controller) precludes the OP giving a traditional public/pairwise which it controls. This prevents the ability for an OP to migrate to or from use of portable identifiers for a user.”

   • 2021-02-23T22:56:08+00:00
8. 

   Kristina Yasuda

   Thank you!

   Which mechanism could we use to bind several subject identifiers among themselves? to prevent identifier of an end-user being tied to the identifier controlled by a malicious actor?

   we could include a property signed by the old identifier that is tied to the new identifier like 'aka’ property in MODERNA porting spec? or just for the reference, DID-CORE spec introduces alsoKnownAs property that has no binding relationship between identifiers and equivalentID / CanonicalID properties that are dependent on the cryptographically deterministic relationship between two identifiers introduced by each DID method.

   • 2021-02-25T16:10:45+00:00
9. 

   Nat Sakimura

   • changed status to open

   Discussed in Mar 15 call.

   It is about the subject confirmation method. Tom expressed uncomfortability in having multiple subs in a token as in a single connection, there is only one subject in OIDC.

   John pointed out that the notion of confirmation method and subject identifier should be disentangled.

   VIttorio expressed that he is not comfortable in just talking on a purely theoretical basis but we should have canonical use-cases.

   • 2021-03-15T23:53:29+00:00
10. 

    Tom Jones

    FIrst, I agree w/ both John and Vittorio.

    To be clear on my position - for one connection session, including any automatic refreshes, there can be one and only one subject identifier at any given point in time. That would allow for a subject identifier to be rolled (in some sense) during the connex, but still at any one time there is only one sub identifier. There can be all kinds of other identifiers, for authenticators or whatever, but only one sub identifier.

    BTW, the DID does not need to be the sub identifier. It’s real purpose is authn (aka verification method), so it can be one of the authn identifiers if that is what the use case is architected to support.

    Also, to be clear, i am mostly interested in long-lived relationships, like an entire life-time, so there could be short-lived sessions with different needs.

    • 2021-03-16T00:34:01+00:00
11. 

    Tobias Looker

    Whilst I do understand the comment that an integration model like that proposed in portable identities does add extra validations rule for an RP, I do still think it is the most consistent path forward that does not bifurcate how RPs currently identify the End-User (e.g via the sub claim). Put another way if we do introduce a new claim of subs to id_tokens, RPs will have to significantly modify their id_token processing logic to suitable identify the End-User.

    Instead if we allow the sub field to take on additional semantics (e.g support cryptographically verifiable identifiers like DIDs or public key finger prints), it is important to note that there is still safe fall back logic that does not break the security model of openid. For example if an OP creates an id_token with an identifier like a did in the sub field and returns it to an RP that does not understand did’s or any form of extended semantics for the sub field, it will revert to identifying the subject like it already does, which is in the context of the domain of the OP (e.g sub + iss is the ambiguous identifier for the End-User). RPs on the other hand that do support the additional validation rules of portable identities can apply these to instead identify the End-User outside of the domain of the IDP.

    Another point I’d like to raise is that the classification of ‘public' ‘private’ and 'transient’ for the subject identifier type is not the same as expressing the relationship the identifier has to the OP. There must be two different classifications here, the former is about expressing the scope or the audience that the particular sub value is used within (e.g with one client or many, or maybe just for a single transaction). The latter is about the domain the subject identifier is defined within (e.g classic sub values are tied to the OPs domain where as DIDs are typically within the domain of the DID method used).

    ‌

    • 2021-03-16T23:40:33+00:00
12. 

    Tom Jones

    Tobias did not address the issue of control of the authentication session which i view as primal. If you want to create a worked out use case that deals with the all the issues, perhaps we can talk again.

    • 2021-03-17T00:18:08+00:00
13. 

    David Waite reporter

    @all To be clear (as someone brought it up to me independently) - I am more trying to get consensus on the problem space rather than this as a solution:

    1. id_tokens have two different security and trust models today for validity/subject verification, lets call them “regular” and “hard-coded SIOP”
    2. The differences in the models are not necessarily clear to implementors who have not researched implementation of the SIOP functionality.
    3. There is a desire to break this partitioning between regular and SIOP by removing the hard-coding of the fixed issuer and custom url scheme - to enable more reliable use, better fall-back scenarios, and javascript-based implementations that have not or cannot override custom URL schemes.
    4. At least one more security/trust model for validity/subject verification is likely to be proposed via portable identifiers - which may need to degrade gracefully or fail if existing deployments are not updated to understand portable identifiers
    5. If a hosted provider wishes to support portable identifiers, they have to worry about migration cases - which means that they may need to assert e.g. both an OP-scoped subject and a portable identifier at the same time.

    Since I dislike just pointing out potential future problems, I wanted to also propose a potential solution (the subs claim)

    I proposed the new claim since we can define the processing rules under it. This gives more control over both how additional functionality would extend the system, and allow for specifying processing behavior when the data is not understood. By default, unrecognized JWT claims are ignored, meaning there are compatibility issues with declaring new security requirements at the top level.

    The duplication between the top-level sub claim and the proposed new claim would potentially allow for backward compatibility behavior to be enabled, for instance a hosted OP which wishes to start exposing portable identifiers could choose to have the sub claim indicate the OP-scoped identifier for the RP, while the subs claim could include both the OP scoped identifier and the portable identifier.

    I also thought that now would be a good time to propose this, since (if people think this is a worthwhile proposal) there is at some conceptual overlap with the in-draft sub_id claim under secevent ( https://datatracker.ietf.org/doc/draft-ietf-secevent-subject-identifiers/ ).

    • 2021-03-17T06:21:25+00:00
14. 

    David Waite reporter

    Which mechanism could we use to bind several subject identifiers among themselves? to prevent identifier of an end-user being tied to the identifier controlled by a malicious actor? 

    The identifiers would be bound in a single statement by the issuer, which hopefully limits the abuse cases to a misled or malicious issuer.

    Conceptually, I tend to think of a user’s account at the RP as having one or more authentication methods, and federated login as being one of those authentication methods (along with username and password, webauthn, etc). SIOP could be one of those kinds of methods as well, not dissimilar to mutual TLS authentication.

    Portable identifiers require this model to be altered a bit, as it dissociates the business process and validation - I have an understanding of how I request an id_token from Microsoft or Google based on federation if that is one of my authentication methods. However, the portability of a portable identifier means the interaction process can vary while the validation of the authenticated message remains the same.

    If I’m adding an OP as an authentication option, I would expect the authentication associated with that kind of identifier to be validated, and then the identifier to be associated with my account. If I’m authenticating and the values have changed (say, I’m authenticating to the OP using my portable identifier and that information is being returned to the RP) then I would expect the RP to prompt whether I want the portable identifier as a new authentication option.

    There are issuers who are known (e.g. Google) who a relying party might make a trust decision on, but with dynamic OIDC, SIOP, and portable identifiers you don’t have that “simple” trusted systems relationship at play.

    we could include a property signed by the old identifier that is tied to the new identifier like 'aka’ property in MODERNA porting spec? or just for the reference, DID-CORE spec introduces alsoKnownAs property that has no binding relationship between identifiers and equivalentID / CanonicalID properties that are dependent on the cryptographically deterministic relationship between two identifiers introduced by each DID method.

    As an RP, I would expect the identifier is part of an authentication method for a user account, and that changes in that identifier are either part of a fully automated and secured process (signed identifier porting statements) or are the result of a user action (even if that action winds up being just informed consent for UX reasons).

    • 2021-03-17T07:13:56+00:00
15. 

    David Waite reporter

    Tobias Looker

    Whilst I do understand the comment that an integration model like that proposed in portable identities does add extra validations rule for an RP, I do still think it is the most consistent path forward that does not bifurcate how RPs currently identify the End-User (e.g via the sub claim). Put another way if we do introduce a new claim of subs to id_tokens, RPs will have to significantly modify their id_token processing logic to suitable identify the End-User.

    RPs are required to significantly modify their processing logic to deal with a non-static set of issuers, let alone SIOP where the messages have a different security model, let alone with the current portable identifiers draft - an id_token from a valid issuer should fail if the new sub_ace claim is not cryptographically validated.

    Instead if we allow the sub field to take on additional semantics (e.g support cryptographically verifiable identifiers like DIDs or public key finger prints), it is important to note that there is still safe fall back logic that does not break the security model of openid. For example if an OP creates an id_token with an identifier like a did in the sub field and returns it to an RP that does not understand did’s or any form of extended semantics for the sub field, it will revert to identifying the subject like it already does, which is in the context of the domain of the OP (e.g sub + iss is the ambiguous identifier for the End-User).

    You can request a particular type of subject (OP scoped, portable identifier). However, if the user has an existing relationship with an OP using an OP scoped identifier, how would you imagine them moving to a portable identifier?

    This legacy fallback is not insecure, but it means my identifier is even less portable than normal - I now must use that particular identifier as part of my authentication process, or I break that RP.

    Another point I’d like to raise is that the classification of ‘public' ‘private’ and 'transient’ for the subject identifier type is not the same as expressing the relationship the identifier has to the OP. There must be two different classifications here, the former is about expressing the scope or the audience that the particular sub value is used within (e.g with one client or many, or maybe just for a single transaction). The latter is about the domain the subject identifier is defined within (e.g classic sub values are tied to the OPs domain where as DIDs are typically within the domain of the DID method used).

    DIDs name the subject within a context - that context can also be conceptually categorized as being public, pairwise, or transient.

    I would expect the subject_type to represent the context of the RP - is the RP receiving a public/correlatable identifier, one specific to the RP context (e.g. sector) or one which will not repeat in the future.

    If the issuer is only able to authenticate DIDs exclusive to the issuer’s context, then that isn’t very portable and shouldn’t be shared as a portable identifier. I would assume an issuer exposing portable identifiers either is exposing an identifier which the subject has stated is public, or has specific knowledge of the DIDs which should be exposed for different contexts.

    • 2021-03-17T07:38:26+00:00
16. 

    David Waite reporter

    Tom Jones

    Tobias did not address the issue of control of the authentication session which i view as primal. If you want to create a worked out use case that deals with the all the issues, perhaps we can talk again.

    Speaking purely in terms of authentication:

    • If I support, receive and validate a token from an issuer using traditional non-SIOP, my understanding is that authentication is of a scoped identifier (sub, issuer)
    • If I support, receive and validate a SIOP token today, my understanding is that authentication is of a self-issued identifier thumbprint
    • If I support and receive a proposed portable identifier-containing token, my understanding is that authentication is of the portable identifier identifier

    My questions are:

    1. How do we deal with this when we are imposing new processing rules on id_tokens. Claims which are not understood must be ignored, and I worry about an id_token being processed under the wrong security model.
    2. What is the business process of dealing with an issuer which supports multiple authentication models?

    Since the different processing models seem tied to different subject “types”, I proposed in kind:

    1. Put the subject security process information under a claim, so that we can declare different processing models from the default JWT model which is ‘ignore what you don’t understand'.
    2. Allow multiple bundles of subject information and security process information to be included, so that a relying party can consume just the one it understands (and potentially act on new subject types, such as prompting the user to register the portable identifier as an authentication method on the user’s account)

    We may have other approaches here, especially for #2.

    I would say though that today the security model of the token and the meaning of the subject is switched by matching a hard-coded issuer value. There are a number of proposals which would at least make this issuer-by-issuer, and I believe portable identifiers would require this to be distinguished message-by-message from a single issuer.

    • 2021-03-17T07:56:50+00:00
17. 

    Tom Jones

    OIDC supports multiple authentication models today with other claims like acr and amr. The RP can request levels of assurance today. In the VC world the RP can request all sorts of (VP) claims with PE (presentation exchange). As the complexity grows the chance of the user OP (wallet) and the RP settling on a accepted level of “IDENTITY” (whatever that might mean) is becoming the sort of chore (user cognitive overload) that has killed other solutions like MTLS and info-cards. (The concept of a user making an informed consent decision from a PE request seems extremely unlikely as it is buried in technology that the normal user could never understand.)

    What i liked in the last siop session was your reporting of mike’s thoughts that a trust federation would be required to “marshall” the options that were appropriate for given session. Then the RP would display choices of the various trust frameworks that met the needs of the RP (a mini-NASCAR menu.) Nearly all “negotiation” would be pre-loaded by the framework.

    • 2021-03-17T17:11:53+00:00
18. 

    Oliver Terbu

    @david_waite: Is this issue been addressed or superseded by more previous issues? In that case we might want to close this issue. If there is no further discussion or activity, we might also want to close this.

    • 2021-09-10T15:20:58+00:00
19. 

    David Waite Account Deactivated

    I am now proposing that rather than DIDs be an entirely new kind of subject, that the subject be a URI within SIOP that is resolvable to an authoritative JWKS, and that JWKS be used to sign the id_token.

    As such, DID subjects would be intertwined with SIOP, as the id_token for traditional OPs are signed differently. This restriction eliminates the possibility of a traditional OP needing to support multiple subject values in parallel, so I’ll close this issue.

    • 2021-09-17T16:09:48+00:00
20. 

    David Waite Account Deactivated

    • changed status to resolved

    • 2021-09-17T16:10:33+00:00
21. Log in to comment