Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

[Phil Hunt <[e-mail]>]

I’m more worried about confusion with OAuth access tokens than with the OIDC profile.

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>







> On Mar 1, 2017, at 11:52 AM, Mike Jones <[e-mail]> wrote:
> 
> What I meant to say in my last sentence was “Given that OpenID Connect Core defines the use of “nonce” in ID Tokens, I think it’s sufficient for OpenID Connect Back-Channel Logout to prohibit its use in Logout Tokens.  Both are OpenID-specific.  I don’t think we need to say anything in the SET spec about OpenID-specific claims.”
>  
> From: Id-event [mailto:[e-mail]] On Behalf Of Mike Jones
> Sent: Wednesday, March 1, 2017 11:48 AM
> To: Phil Hunt <[e-mail]>; William Denniss <[e-mail]>
> Cc: ID Events Mailing List <[e-mail]>
> Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens
>  
> In many of the cases, the issuer of the SET will be the same as the issuer of the subject of the event, since it’s the issuer that’s authoritative for both in most cases.  Only in the case that the party issuing the event is different from the party that the event is about (which I think will be a less common case) will it be necessary to have a second issuer.  And in that case, we already have syntax for that second issuer – which becomes a parameter to the event.
>  
> The way that “iss” and “sub” are bound together syntactically is that they’re members of the same JSON object.  If you want to have a second issuer and subject, they would also be members of a JSON object – in that case, the JSON object for the event parameters.
>  
> As I wrote in the (now forked) response to William, we should steer clear of requiring people to use claims in unnatural ways.  For instance, “aud” (audience) restrictions would violate this principle.
>  
> Given that OpenID Connect Core the use of “nonce” in ID Tokens, I think it’s sufficient for OpenID Connect Back-Channel Logout to prohibit its use in Logout Tokens.  Both are OpenID-specific.  I don’t think we need to say anything in the SET spec about OpenID-specific claims.
>  
>                                                                 -- Mike
>  
> From: Phil Hunt [mailto:[e-mail] <mailto:[e-mail]>] 
> Sent: Wednesday, March 1, 2017 11:37 AM
> To: William Denniss <[e-mail] <mailto:[e-mail]>>
> Cc: Mike Jones <[e-mail] <mailto:[e-mail]>>; ID Events Mailing List <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens
>  
> +1  I like the idea of prohibiting ‘nonce”.  Would be great to have a proposal for the “aud” text.
>  
> I’m neutral on this stuff. In proposing 2, I was responding to the awkwardness that Yaron pointed. I was trying to think of something that cleanly separates SET use of subject from the way access tokens use it. I wanted to bind together the “iss” and “sub” as they often go together. I’m not a fan of having “iss” colliding with the issuer of the SET….I wish there was a better way to keep “sub” and “iss” closer together.
>  
> Phil
>  
> Oracle Corporation, Identity Cloud Services & Identity Standards
> @independentid
> www.independentid.com <http://www.independentid.com/>
> [e-mail] <mailto:[e-mail]>
>  
>  
>  
>  
>  
> 
>  
> On Mar 1, 2017, at 11:20 AM, William Denniss <[e-mail] <mailto:[e-mail]>> wrote:
>  
> My vote is for #1.  Iss and sub should take the definition from JWT.
>  
> I fear that following the "access token confusion mitigation" logic here basically means that "sub" can only be used by authorization & authentication protocols which is wasn't the intent of the spec <https://tools.ietf.org/html/rfc7519#section-4.1>.  What is the point of these standard claims if we can't use them? Will every new spec prohibit/rename a different standard claim? This isn't scalable, and is super confusing.
>  
> Back-channel logout "breaks" the id token mix-up by prohibiting <https://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken> 'nonce'.  When I spoke to Breno about the overall risk, he suggested not reusing "aud" in other systems (like RISC, SCIM, etc). OpenID Connect defines "aud" to be the client-id. If *every other spec* uses a URI-based approach for aud and recommends not re-using audience URIs between systems, then we can avoid conflicts and usage mix-ups.
>  
> If I recall correctly in Buenos Aires, the preference of +Mike was to keep "sub" for compatibility with Backchannel Logout.
>  
> I hope we can avoid going around in circles on this security topic, how about I propose some new text for https://tools.ietf.org/html/draft-ietf-secevent-token-00#section-3.5 <https://tools.ietf.org/html/draft-ietf-secevent-token-00#section-3.5> capturing the "aud" suggestion?  We can confine all such "access token confusion" matters to that section, and just build the best SET spec we can without needing to bake in hacks.
>  
> Mandating that different systems use non-overlapping "aud" sets doesn't not sound like a hack to me at all (unlike renaming "sub"), since the audience of a SET stream is surely different to that of an AuthZ/N token.
>  
>  
>  
> On Wed, Mar 1, 2017 at 10:27 AM, Phil Hunt <[e-mail] <mailto:[e-mail]>> wrote:
> In the comments on idtoken-07, Yaron raised concerns around the confusion of “iss” of the subject of the event vs. issuer of the event.  The current text says that if there is a need to distinguish between “iss” of the “sub” vs. “iss” of the event, then the event should place the “iss” of the subject in the event payload area.
>  
> I agree this does seem awkward.
>  
> I have been thinking a related concern, that a SET could be confused as an access token if it has a “sub” value.  If we stop using “sub” then we’re potentially causing web access management systems to reject SETs as invalid access tokens — this is theoretically a GOOD THING.
>  
> PLEASE INDICATE 1 or 2, or provide additional discussion. 
>  
> Two options:
>  
> 1. Leave as is.
>  
> 2.  Create a new attribute object, “esub” (event subject) which is a JSON object that contains the attributes needed to identify the subject.  For example:
>  
> We currently have:
>    {
>      "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
>  
>      "sub": "248289761001",
>      "iat": 1458496025,
>      "iss": "https://my.examplemed.com <https://my.examplemed.com/>",
>      "aud": [
>        "https://rp.example.com <https://rp.example.com/>"
>      ],
>      "events": {
>        "https://openid.net/heart/specs/consent.html <https://openid.net/heart/specs/consent.html>":{
>          "iss":"https://connect.example.com <https://connect.example.com/>",
>          "consentUri":[
>            "https://terms.examplemed.com/labdisclosure.html#Agree <https://terms.examplemed.com/labdisclosure.html#Agree>"
>          ]
>        }
>      }
>    }
>  
> Could be represented as:
>    {
>      "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
>  
>      “esub": {
>        “sub”:"248289761001”,
>        "iss":"https://connect.example.com <https://connect.example.com/>”
>      }
>      "iat": 1458496025,
>      "iss": "https://my.examplemed.com <https://my.examplemed.com/>",
>      "aud": [
>        "https://rp.example.com <https://rp.example.com/>"
>      ],
>      "events": {
>        "https://openid.net/heart/specs/consent.html <https://openid.net/heart/specs/consent.html>":{
>          "consentUri":[
>            "https://terms.examplemed.com/labdisclosure.html#Agree <https://terms.examplemed.com/labdisclosure.html#Agree>"
>          ]
>        }
>      }
>    }
>  
> Comments:
> * “sub” remains untouched in the sense that it retains the meaning used in traditional access tokens. 
> * “esub” contains the full information to address the subject.  No need to look around for a second “iss” (which may or may not be there)
>  
> To do this would require defining “esub” and sub-attributes like, “iss”, “sub” (which follow current defs), and probably “uri” for those entities that are referenceable as a URI.  Examples of URI subjects:
> *  in implicit federation (from RISC):   “uri”:”mailto:[e-mail] <mailto:[e-mail]>”
> *  in SCIM where resources have URIs:  “uri”:”https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 <https://scim.example.com/Users/44f6142df96bd6ab61e7521d9>"
>  
> One catch. Profiling specs would not be able to define new ways of addressing subjects with esub.
>  
> Phil
>  
> Oracle Corporation, Identity Cloud Services & Identity Standards
> @independentid
> www.independentid.com <http://www.independentid.com/>
> [e-mail] <mailto:[e-mail]>
>  
>  
>  
>  
>  
> 
>  
> 
> _______________________________________________
> Id-event mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> _______________________________________________
> Id-event mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> _______________________________________________
> Id-event mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>