Subject: [Id-event] Discussion on use of "sub" and confusion as ID Token

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Aug 2016 11:07:50 -0700

The authors have been having a discussion with regards to using the “sub” claim in the top level. I think it is important to try and get this discussion back to the main group. My apologies for the long note. I wanted to get all the pros and cons on the table (hint:  please add if I missed any)...

A question remains should “sub” be usable at the top level.  The downside of this approach is that a SET could potentially be presented as an access or iD token and might initially be confused because existing code does not know it needs to look for an “events” attribute.  The SET and ID Token for all intensive purposes are the same since a SET just has something extra (the events claim).

There is also the question that if OIDC Logout uses it in the top level, may other events use it? RFC7519 defines “sub” as a String or URI value. For example, in SCIM events, the “sub” value could be a SCIM Resource URI that indicates the resource whose state has changed.  In OAuth it could be defined as the token identifier of the token that has been revoked.  A SET about blacklisting an IP address might put the IP address in sub.

So there are three options (Option A seems to be favoured so far):  

A.  Sub at Top Level:  “sub” generally used to reference the Security Subject the SET is talking about.  It uses a more general english language intent of subject rather than the traditional use as seen in SAML or OpenID Connect.  Regardless it is still compliant with RFC7519 (a String or URI).

This would tend to lead to a style of SETs where the envelope carries the validation information, the type of event, and the subject of the event. Additional data goes in the payload. An advantage of this style, is that for many events, the only thing needed is the event type and the subject.  No payloads would be needed.

For events that don’t want payload, it is probably ok for profiling event standards to define more claims at the top level. They MUST be registered in the JWT registry. Profiling events can avoid registration by just putting their attributes/claims in the payload area as described in the spec.  However, this would be inconsistent with those that use payloads with unregistered claims.  I point out that we switched from registered event URNs to URIs to avoid registration.  Hence the move to payload objects to eliminate registration for attributes/claims.  

This still has the negatives of being confusable as an ID Token by existing code. There has been a discussion that “iss” and/or “aud” should actually be different and the receiver should detect that.  However in the OIDC Logout case, by design, the “iss” value would be the same.  The “aud” would also likely be the same unless the spec indicates that an alias “aud” be used even though the audience may be the same entity in both cases.

B. Exclusive-Use of Sub: “sub” is interpreted to by traditional definition and is reserved for OAuth tokens and OIDC Connect usage only.  In order to  avoid confusing, all profiling event specs should NOT use “sub” in the top level except for OIDC.

This has the disadvantage that OIDC requires special handling in terms of a general use event library, but on the other hand a Logout Event might be handled directly by existing ID Token code.

This still has the disadvantage that an SET could be confused for an ID Token.

C. No-Top-Level Data: In order to more aggressively avoid confusion of SETs as ID Tokens, make it mandatory that SETs may not contain a “sub” value at the top level.  The OIDC Logout Event, for example, would then include a “sub” value in the payload area. This should cause existing relying parties to fail correctly.  

This would provide a maximal difference form a IDToken or access token.

This would have the advantage that envelopes contain no data, and that every SET has a payload where the data is found. It requires more parsing in some cases, but it is at least consistent. While we don’t expect general processors like in SOAP for distribution (much of it is point to point and very contextually driven), I personally expect to see:
  *  Development of general purpose libraries and tools that are used enhance protocols and systems 
  *  Audit and threat analysis systems will be looking at some events historically. These will tend to merge multiple event feeds.

Mike Jones also suggested using the “cty” (content type) header attribute from JWT.  I think most code today has this set to ignore or fixed as “JWT”.  I wonder what current implements would feel if we introduced a “cty” value of “SET”?  Would that help?

Thanks for your comments.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 24 Aug 2016 12:51:09 -0700

On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt <[email-masked]> wrote:

>
> The authors have been having a discussion with regards to using the “sub”
> claim in the top level. I think it is important to try and get this
> discussion back to the main group. My apologies for the long note. I wanted
> to get all the pros and cons on the table (hint:  please add if I missed
> any)...
>
> A question remains should “sub” be usable at the top level.  The downside
> of this approach is that a SET could potentially be presented as an access
> or iD token and might initially be confused because existing code does not
> know it needs to look for an “events” attribute.  The SET and ID Token for
> all intensive purposes are the same since a SET just has something extra
> (the events claim).
>
> There is also the question that if OIDC Logout uses it in the top level,
> may other events use it? RFC7519 defines “sub” as a String or URI value.
> For example, in SCIM events, the “sub” value could be a SCIM Resource URI
> that indicates the resource whose state has changed.  In OAuth it could be
> defined as the token identifier of the token that has been revoked.  A SET
> about blacklisting an IP address might put the IP address in sub.
>
> *A.  Sub at Top Level:*  “sub” generally used to reference the Security
> Subject the SET is talking about.  It uses a more general english language
> intent of subject rather than the traditional use as seen in SAML or OpenID
> Connect.  Regardless it is still compliant with RFC7519 (a String or URI).
>
> This would tend to lead to a style of SETs where the envelope carries the
> validation information, the type of event, and the subject of the event.
> Additional data goes in the payload. An advantage of this style, is that
> for many events, the only thing needed is the event type and the subject.
> No payloads would be needed.
>
> For events that don’t want payload, it is probably ok for profiling event
> standards to define more claims at the top level. They MUST be registered
> in the JWT registry. Profiling events can avoid registration by just
> putting their attributes/claims in the payload area as described in the
> spec.  However, this would be inconsistent with those that use payloads
> with unregistered claims.  I point out that we switched from registered
> event URNs to URIs to avoid registration.  Hence the move to payload
> objects to eliminate registration for attributes/claims.
>
> This still has the negatives of being confusable as an ID Token by
> existing code. There has been a discussion that “iss” and/or “aud” should
> actually be different and the receiver should detect that.  However in the
> OIDC Logout case, by design, the “iss” value would be the same.  The “aud”
> would also likely be the same unless the spec indicates that an alias “aud”
> be used even though the audience may be the same entity in both cases.
>
> *B. Exclusive-Use of Sub:* “sub” is interpreted to by traditional
> definition and is reserved for OAuth tokens and OIDC Connect usage only.
> In order to  avoid confusing, all profiling event specs should NOT use
> “sub” in the top level except for OIDC.
>
> This has the disadvantage that OIDC requires special handling in terms of
> a general use event library, but on the other hand a Logout Event might be
> handled directly by existing ID Token code.
>
> *C. No-Top-Level Data:* In order to more aggressively avoid confusion of
> SETs as ID Tokens, make it mandatory that SETs may not contain a “sub”
> value at the top level.  The OIDC Logout Event, for example, would then
> include a “sub” value in the payload area. This should cause existing
> relying parties to fail correctly.
>
> This would have the advantage that envelopes contain no data, and that
> every SET has a payload where the data is found. It requires more parsing
> in some cases, but it is at least consistent. While we don’t expect general
> processors like in SOAP for distribution (much of it is point to point and
> very contextually driven), I personally expect to see:
>   *  Audit and threat analysis systems will be looking at some events
> historically. These will tend to merge multiple event feeds.
>
> Mike Jones also suggested using the *“cty”* (content type) header
> attribute from JWT.  I think most code today has this set to ignore or
> fixed as “JWT”.  I wonder what current implements would feel if we
> introduced a “cty” value of “SET”?  Would that help?
>

I think it is very important to be able to clearly distinguish different
types of JWT tokens. For example, not being able to cross post a Security
Event Token as an Id Token.

Reading RFC 7519 I don't think cty fits the bill, but I could be wrong. cty
is a header parameter used by the crypto algorithm and the default value is
JWT. We need to distinguish sub-types of JWT, and it should be a claim
inside the JWT.

With the above issue in mind, I think option A is the cleanest solution.

> www.independentid.com
> [email-masked]
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Aug 2016 20:13:02 +0000

Just for completeness, the other way of distinguishing between JWTs is the “typ” value.  (The difference between “cty” and “typ” is that “cty” is the type of the content of the JWS/JWE payload whereas “typ” is the type of the entire object.)  You’ll see that “typ” is even used in the JWS examples.  “typ” is described at https://tools.ietf.org/html/rfc7515#section-4.1.9 and https://tools.ietf.org/html/rfc7519#section-5.1.  “cty” is described at https://tools.ietf.org/html/rfc7515#section-4.1.10 and https://tools.ietf.org/html/rfc7519#section-5.2.

Placing restrictions on “sub” would unnecessary and counter-productive.  It’s the kind of complexity that could result in the ADs and IESG raising questions that would stand in the way of acceptance of the individual submission.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Marius Scurtescu
Sent: Wednesday, August 24, 2016 12:51 PM
To: Phil Hunt <[email-masked]>
Cc: [email-masked]
Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token

On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

I think it is very important to be able to clearly distinguish different types of JWT tokens. For example, not being able to cross post a Security Event Token as an Id Token.

Reading RFC 7519 I don't think cty fits the bill, but I could be wrong. cty is a header parameter used by the crypto algorithm and the default value is JWT. We need to distinguish sub-types of JWT, and it should be a claim inside the JWT.

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Aug 2016 17:31:47 -0300

The idea for cty was to allow a JWS to encapsulate things like a binary GIF as an example.   I think using it for Distinguishing subtypes of JWT would be a stretch.

I am most comfortable with A.   I think that adding a JWT type claim at the top level may also be useful going forward to avoid misinterpretation.

John B.
> On Aug 24, 2016, at 4:51 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> On Wed, Aug 24, 2016 at 11:07 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Aug 2016 20:49:43 +0000

I’m not advocating “typ” or “cty” for any particular use case.  I was just bringing them into the discussion because people were talking about type fields and some might not be aware of the type fields that already part of the standards.

A general-purpose JWT type claim seems only to be useful to me in use cases in which multiple kinds of unrelated JWTs are valid in the same context (the SOAP pattern).  Again, there may be valid such use cases, but they don’t come up in events use cases, in which events listeners should only be listening for specific families of events and not arbitrary JWTs.

To the particular point about whether an event JWT can be confused with an ID Token, two complementary preventions seem pertinent:

·       Require that any OP that issues events (such as logout tokens) *also* reject any purported ID Tokens that contain an “events” claim.  This new rule needs to only be put in place at the time the OP starts issuing JWTs that are not ID Tokens.  The problem can’t occur before that.

·       Require that non-ID Tokens not contain a “nonce”, as is already the case for logout tokens.

Either of these would do the job.  Doing both is defense in depth.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, August 24, 2016 1:32 PM
To: Marius Scurtescu <[email-masked]>
Cc: [email-masked]; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token

John B.
On Aug 24, 2016, at 4:51 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

Phil

@independentid
www.independentid.com<http://www.independentid.com/>
[email-masked]<mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Aug 2016 13:59:45 -0700

John,

Did you mean adding a “jwt_type” attribute (that becomes a registered JWT claim) OR adding a new type value for the JWT header “typ”?  Note for everyone’s convenience from 7519:

The "typ" (type) Header Parameter defined by [JWS <https://tools.ietf.org/html/rfc7519#ref-JWS>] and [JWE <https://tools.ietf.org/html/rfc7519#ref-JWE>] is used
   by JWT applications to declare the media type [IANA.MediaTypes <https://tools.ietf.org/html/rfc7519#ref-IANA.MediaTypes>] of
   this complete JWT.  This is intended for use by the JWT application
   when values that are not JWTs could also be present in an application
   data structure that can contain a JWT object; the application can use
   this value to disambiguate among the different kinds of objects that
   might be present.  It will typically not be used by applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.  While
   media type names are not case sensitive, it is RECOMMENDED that "JWT"
   always be spelled using uppercase characters for compatibility with
   legacy implementations.  Use of this Header Parameter is OPTIONAL.

What is concerning is the line that says: 
It will typically not be used by applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.

If it is typically ignored, then having it “typ” be “SET” may not help much initially. But at least it is more definitive.

If the group is comfortable, I am ok with making “typ” be “SET”.  It is one more distinguishing item.  

Regardless, I will also put a cautionary note in the security considerations that if issuing SETs to audiences that also receive JWTs, that appropriate care be taken not to confuse if somehow a hacker is able to present the SET as if it were a JWT to gain access (e.g. in an authorization header).  Normally this should not be possible as I would assume SETs are passed via something like an HTTP POST back-channel.

Phil

@independentid

> On Aug 24, 2016, at 1:31 PM, John Bradley <[email-masked]> wrote:
> 
>> On Aug 24, 2016, at 4:51 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Aug 2016 18:24:11 -0300

I was saying that cty was wrong for this.  

If you look at the definition of typ in JWS https://tools.ietf.org/html/rfc7515#page-13 <https://tools.ietf.org/html/rfc7515#page-13>  you can see that it is really intended to be the media type of the complete JWS/JWE and is omitted or set to JWT if it is a compact JWT.     Setting it to SET seems wrong as it is still a JWT.   I was recommending considering a JWT top level claim in the JWT registry.

John B.

> On Aug 24, 2016, at 5:59 PM, Phil Hunt <[email-masked]> wrote:
> 
> John,
> 
>> On Aug 24, 2016, at 1:31 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Aug 2016 21:31:04 +0000

A spec could create a top-level JWT type claim, but I’d assert that it’s out of scope for the Events spec.  It would probably need to be its own spec and say basically “use it if you’re in use cases in which it’s useful to distinguish between things”.

From: Id-event [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, August 24, 2016 2:24 PM
To: Phil Hunt <[email-masked]>
Cc: [email-masked]; Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token

If you look at the definition of typ in JWS https://tools.ietf.org/html/rfc7515#page-13  you can see that it is really intended to be the media type of the complete JWS/JWE and is omitted or set to JWT if it is a compact JWT.     Setting it to SET seems wrong as it is still a JWT.   I was recommending considering a JWT top level claim in the JWT registry.

John B.

On Aug 24, 2016, at 5:59 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

John,

The "typ" (type) Header Parameter defined by [JWS<https://tools.ietf.org/html/rfc7519#ref-JWS>] and [JWE<https://tools.ietf.org/html/rfc7519#ref-JWE>] is used

   by JWT applications to declare the media type [IANA.MediaTypes<https://tools.ietf.org/html/rfc7519#ref-IANA.MediaTypes>] of

Phil

@independentid

On Aug 24, 2016, at 1:31 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:

John B.

Phil

@independentid

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Aug 2016 18:32:39 -0300

The possible rational for a JWT type claim is not for multiplexing multiple types in the same channel but to prevent having one protocol get the AS to sign a JWT that could be mis interpreted by another protocol in a different channel.   These sorts of attacks have happened to other things in the past.

It is true that the lack of a nonce now and token binding in the future would stop a Connect client from accepting a events token.   

The audience could also be different and that would also stop them from being accepted. (I am not recommending that but it is possible)

I think we have ways to deal with it for connect id_tokens.   My concern going forward is that there will be a lot of other protocols using JWT so it may be useful for SET and others to have a jwt_type claim that could be used to prevent cross channel attacks.   It is also possible for other things to mistakenly process id_tokens if audiences are reused.

It may stop some horrible mistake down the road, that potentially has nothing to do with Connect. 

In some ways the simple thing is for clients to use district audiences across protocols, but that would add some complexity to logout as we all ready have a logical audience for the event.

John B.

> On Aug 24, 2016, at 5:49 PM, Mike Jones <[email-masked]> wrote:
> 
>   <>
> www.independentid.com <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
> 
>  
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Aug 2016 14:41:48 -0700

Ok.  Can we agree that a strong security consideration would be the appropriate remedy?

The text (not finished yet) might cover the following:

Audiences that receive both JWTs (e.g. as access tokens) and SETs for security events should take care to ensure that a SET passed in a channel where it could be confused as an access token MUST take care to evaluate:
* The presence/absence of “events” claim
* That the “aud” value is correct.  And where possible the SET “aud” and the access token “aud” are in fact different even if it is the same service entity.
* That access tokens and SETs SHOULD NOT be received over the same channel and at minimum SHOULD be separate endpoints. e.g. access tokens via the authorization header of a resource service, versus SETs received over HTTP POST at a specific web URI associated with the subscription.
* Check for the presence of a “nonce” in the case of an OpenID Connect id_token.

Phil

@independentid

> On Aug 24, 2016, at 2:31 PM, Mike Jones <[email-masked]> wrote:
> 
> On Aug 24, 2016, at 5:59 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>  
> John,
>

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Aug 2016 18:44:53 -0300

If you look at the definition of typ in JWS https://tools.ietf.org/
html/rfc7515#page-13  you can see that it is really intended to be the
media type of the complete JWS/JWE and is omitted or set to JWT if it is a
compact JWT.     Setting it to SET seems wrong as it is still a JWT.   I
was recommending cosidering a JWT

John,

Did you mean adding a “jwt_type” attribute (that becomes a registered JWT
claim) OR adding a new type value for the JWT header “typ”?  Note for
everyone’s convenience from 7519:

The "typ" (type) Header Parameter defined by [JWS
<https://tools.ietf.org/html/rfc7519#ref-JWS>] and [JWE
<https://tools.ietf.org/html/rfc7519#ref-JWE>] is used
   by JWT applications to declare the media type [IANA.MediaTypes
<https://tools.ietf.org/html/rfc7519#ref-IANA.MediaTypes>] of
   this complete JWT.  This is intended for use by the JWT application
   when values that are not JWTs could also be present in an application
   data structure that can contain a JWT object; the application can use
   this value to disambiguate among the different kinds of objects that
   might be present.  It will typically not be used by applications when
   it is already known that the object is a JWT.  This parameter is
   ignored by JWT implementations; any processing of this parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.  While
   media type names are not case sensitive, it is RECOMMENDED that "JWT"
   always be spelled using uppercase characters for compatibility with
   legacy implementations.  Use of this Header Parameter is OPTIONAL.

It will typically not be used by applications when
   it is already known that the object is a JWT.  *This parameter is
   ignored by JWT implementations*; any processing of this parameter is
   performed by the JWT application.  If present, it is RECOMMENDED that
   its value be "JWT" to indicate that this object is a JWT.

If it is typically ignored, then having it “typ” be “SET” may not help much
initially. But at least it is more definitive.

If the group is comfortable, I am ok with making “typ” be “SET”.  It is one
more distinguishing item.

Regardless, I will also put a cautionary note in the security
considerations that if issuing SETs to audiences that also receive JWTs,
that appropriate care be taken not to confuse if somehow a hacker is able
to present the SET as if it were a JWT to gain access (e.g. in an
authorization header).  Normally this should not be possible as I would
assume SETs are passed via something like an HTTP POST back-channel.

Phil

@independentid
www.independentid.com
[email-masked]

The idea for cty was to allow a JWS to encapsulate things like a binary GIF
as an example.   I think using it for Distinguishing subtypes of JWT would
be a stretch.

I am most comfortable with A.   I think that adding a JWT type claim at the
top level may also be useful going forward to avoid misinterpretation.

John B.

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Aug 2016 18:46:51 -0300

Yes,  on one of the calls we talked about it being a separate spec to
register the claim and then events could use it.

On Wed, Aug 24, 2016 at 6:31 PM, Mike Jones <[email-masked]>
wrote:

> A spec could create a top-level JWT type claim, but I’d assert that it’s
> out of scope for the Events spec.  It would probably need to be its own
> spec and say basically “use it if you’re in use cases in which it’s useful
> to distinguish between things”.
>
>
>
> *From:* Id-event [mailto:[email-masked]] *On Behalf Of *John
> Bradley
> *Sent:* Wednesday, August 24, 2016 2:24 PM
> *To:* Phil Hunt <[email-masked]>
> *Cc:* [email-masked]; Marius Scurtescu <[email-masked]>
> *Subject:* Re: [Id-event] Discussion on use of "sub" and confusion as ID
> Token
>
>
>
> was recommending considering a JWT top level claim in the JWT registry.
>
>
>
> John B.
>
>
>
>
>
>    it is already known that the object is a JWT.  *This parameter is*
>
> *   ignored by JWT implementations*; any processing of this parameter is
>
> If it is typically ignored, then having it “typ” be “SET” may not help
> much initially. But at least it is more definitive.
>
>
>
> The idea for cty was to allow a JWS to encapsulate things like a binary
> GIF as an example.   I think using it for Distinguishing subtypes of JWT
> would be a stretch.
>
>
>
> I am most comfortable with A.   I think that adding a JWT type claim at
> the top level may also be useful going forward to avoid misinterpretation.
>
>
>
> John B.
>
> Reading RFC 7519 I don't think cty fits the bill, but I could be wrong.
> cty is a header parameter used by the crypto algorithm and the default
> value is JWT. We need to distinguish sub-types of JWT, and it should be a
> claim inside the JWT.
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Aug 2016 21:50:27 +0000

I would strongly oppose events requiring use of it, because it’s not necessary for an event stream.  It would be unnecessary baggage.

I agree with Phil that strong security considerations is as far as we should go in the Event Token spec.

                                                       -- Mike

From: John Bradley [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 2:47 PM
To: Mike Jones <[email-masked]>
Cc: Phil Hunt <[email-masked]>; [email-masked]; Marius Scurtescu <[email-masked]>
Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token

Yes,  on one of the calls we talked about it being a separate spec to register the claim and then events could use it.

On Wed, Aug 24, 2016 at 6:31 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
A spec could create a top-level JWT type claim, but I’d assert that it’s out of scope for the Events spec.  It would probably need to be its own spec and say basically “use it if you’re in use cases in which it’s useful to distinguish between things”.

From: Id-event [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of John Bradley
Sent: Wednesday, August 24, 2016 2:24 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token

John B.

John,

Phil

@independentid

John B.

Phil

@independentid

---

From: Mike Jones <[email-masked]>
Date: Wed, 24 Aug 2016 21:55:35 +0000

I’ll add one other thought which is behind what I wrote below.  A good spec solves one thing and solves it well.  The thing for the events spec to solve is defining a standard way to represent an event in a JWT.  It should stop there.

Distinguishing between all JWTs is a different problem, which is why (if any of us ever decide to solve it) it should be in a different, unrelated spec.  But again, I’m leery of this in the first place, because the primary use of it is to enable SOAP-style message dispatching.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, August 24, 2016 2:50 PM
To: John Bradley <[email-masked]>
Cc: Marius Scurtescu <[email-masked]>; [email-masked]; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token

                                                       -- Mike

From: John Bradley [mailto:[email-masked]]
Sent: Wednesday, August 24, 2016 2:47 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Phil Hunt <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Discussion on use of "sub" and confusion as ID Token

John B.

John,

Phil

@independentid

John B.

Phil

@independentid

---

From: John Bradley <[email-masked]>
Date: Wed, 24 Aug 2016 18:56:20 -0300

The problem is a bad guy getting a SET JWT and replaying it against any
other channel that takes JWT such as access tokens.

All protocols that receive JWT need to ensure that they are valid.  one way
to do that is to have different logical audiences for different protocols.

The fact that JWT ignore claims that are not understood gives us great
flexibility but also opens the possibility of cross protocol attacks.

This will be a general problem for anything using JWT bearer tokens as it
can be for protocols using SAML bearer.  Even with proof of possession a
malicious client could perhaps generate a cross channel privilege
escalation.

I think this is potential general problem.

On Wed, Aug 24, 2016 at 6:41 PM, Phil Hunt <[email-masked]> wrote:

> Audiences that receive both JWTs (e.g. as access tokens) and SETs for
> security events should take care to ensure that a SET passed in a channel
> where it could be confused as an access token MUST take care to evaluate:
> * That the “aud” value is correct.  And where possible the SET “aud” and
> the access token “aud” are in fact different even if it is the same service
> entity.
> * That access tokens and SETs SHOULD NOT be received over the same channel
> and at minimum SHOULD be separate endpoints. e.g. access tokens via the
> authorization header of a resource service, versus SETs received over HTTP
> POST at a specific web URI associated with the subscription.
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *John Bradley

---

From: Phil Hunt <[email-masked]>
Date: Wed, 24 Aug 2016 15:04:55 -0700

+1  This has been my concern.

I think Mike is right that the correction of adding a type does not belong in SET - but mainly because, you would not expect an implementer of JWTs for the purpose of access tokens would think to look for a security consideration in an event token spec.

Phil

@independentid

> On Aug 24, 2016, at 2:56 PM, John Bradley <[email-masked]> wrote:
> 
> The problem is a bad guy getting a SET JWT and replaying it against any other channel that takes JWT such as access tokens. 
> 
> All protocols that receive JWT need to ensure that they are valid.  one way to do that is to have different logical audiences for different protocols.
> 
> The fact that JWT ignore claims that are not understood gives us great flexibility but also opens the possibility of cross protocol attacks.
> 
> This will be a general problem for anything using JWT bearer tokens as it can be for protocols using SAML bearer.  Even with proof of possession a malicious client could perhaps generate a cross channel privilege escalation.
> 
> On Wed, Aug 24, 2016 at 6:41 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> On Aug 24, 2016, at 2:31 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of John Bradley
>> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>; Marius Scurtescu <[email-masked] <mailto:[email-masked]>>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 24 Aug 2016 16:25:17 -0700

On Wed, Aug 24, 2016 at 2:56 PM, John Bradley <[email-masked]> wrote:

> All protocols that receive JWT need to ensure that they are valid.  one
> way to do that is to have different logical audiences for different
> protocols.
>

+1

>> * That access tokens and SETs SHOULD NOT be received over the same
>> channel and at minimum SHOULD be separate endpoints. e.g. access tokens via
>> the authorization header of a resource service, versus SETs received over
>> HTTP POST at a specific web URI associated with the subscription.
>> If you look at the definition of typ in JWS https://tools.ietf.org/htm
>> l/rfc7515#page-13  you can see that it is really intended to be the