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

[William Denniss <[e-mail]>]

On Wed, Mar 1, 2017 at 11:47 AM, Mike Jones <[e-mail]>
wrote:

> 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.
>

+1


>
>
> 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.
>

I wasn't suggesting a normative restriction, rather a security
consideration. One that could accommodate the Logout use-case, but
hopefully avoid other people accidentally clobbering Connect.


>
>
> 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.
>

+1


>
>
>                                                                 -- Mike
>
>
>
> *From:* Phil Hunt [mailto:[e-mail]]
> *Sent:* Wednesday, March 1, 2017 11:37 AM
> *To:* William Denniss <[e-mail]>
> *Cc:* Mike Jones <[e-mail]>; ID Events Mailing List <
> [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
>
> [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Mar 1, 2017, at 11:20 AM, William Denniss <[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/htm
> l/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]> 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",
>
>      "aud": [
>
>        "https://rp.example.com"
>
>      ],
>
>      "events": {
>
>        "https://openid.net/heart/specs/consent.html":{
>
>          "iss":"https://connect.example.com",
>
>          "consentUri":[
>
>            "https://terms.examplemed.com/labdisclosure.html#Agree"
>
>          ]
>
>        }
>
>      }
>
>    }
>
>
>
> Could be represented as:
>
>    {
>
>      "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
>
>
>
>      “esub": {
>
>        “sub”:"248289761001”,
>
>        "iss":"https://connect.example.com”
>
>      }
>
>      "iat": 1458496025,
>
>      "iss": "https://my.examplemed.com",
>
>      "aud": [
>
>        "https://rp.example.com"
>
>      ],
>
>      "events": {
>
>        "https://openid.net/heart/specs/consent.html":{
>
>          "consentUri":[
>
>            "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]
> <[e-mail]>”
>
> *  in SCIM where resources have URIs:  “uri”:”https://scim.example.c
> om/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
>
> [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>
>