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

From: Phil Hunt <[email-masked]>
Date: Wed, 1 Mar 2017 10:27:59 -0800

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"
>      ],
>      "events": {
>        "https://openid.net/heart/specs/consent.html <https://openid.net/heart/specs/consent.html>":{
>          "iss":"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”
     }
     "iat": 1458496025,
     "iss": "https://my.examplemed.com <https://my.examplemed.com/>",
     "aud": [
       "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:[email-masked]”
*  in SCIM where resources have URIs:  “uri”:”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/>[email-masked] <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Mar 2017 18:33:04 +0000

Leave this as-is.  Adding additional claims that have the same meanings as existing claims but that use different syntax is needless complexity.

Like JWTs, we should keep SETs as simple as possible.  Also like JWTs, particular events will use the claims that they need.  This is as it should be.

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, March 1, 2017 10:28 AM
To: ID Events Mailing List <[email-masked]>
Subject: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Two options:

1. Leave as is.

We currently have:

   {

     "sub": "248289761001",

     "iat": 1458496025,

     "iss": "https://my.examplemed.com<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"

         ]

       }

     }

   }

Could be represented as:

   {

     “esub": {

       “sub”:"248289761001”,

     }

     "iat": 1458496025,

     "iss": "https://my.examplemed.com<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:

Phil

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

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Mar 2017 11:20:44 -0800

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
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 <[email-masked]> 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 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.
>
> 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:
>
>    {
>      "iss": "https://my.examplemed.com",
>      "aud": [
>        "https://rp.example.com"
>      ],
>      "events": {
> "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:
> * “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:[email-masked]
> <[email-masked]>”
> 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, 1 Mar 2017 19:33:47 +0000

Hi William,

I appreciate you supporting using the standard definitions for “sub” and “iss”.  That said, I then find it confusing that you are suggesting that people be prohibited from using “aud” (audience) in the standard way.

I’ll also note that if you prohibit using “aud” in the standard way, you’ll both break the usage in the OpenID Connect Logout Token http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken and in SETs https://tools.ietf.org/html/draft-ietf-secevent-token-00#section-2.1.  Please let’s not go there.

Implementations using both ID Tokens and SETs can already unambiguously distinguish between them by the presence of the “events” claim.  ID Tokens don’t use “events” whereas SETs do.  The fact that “nonce” is present in an ID Token but not SETs provides an extra means of rejecting SETs in ID Token contexts.  I don’t see there as being any actual practical problem to solve that rises to the level of causing us to do unnatural things to claims usage.

                                                                -- Mike

From: William Denniss [mailto:[email-masked]]
Sent: Wednesday, March 1, 2017 11:21 AM
To: Phil Hunt <[email-masked]>; Mike Jones <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

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 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 <[email-masked]<mailto:[email-masked]>> 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.

Two options:

1. Leave as is.

We currently have:

   {

     "sub": "248289761001",

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com"

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Could be represented as:

   {

     “esub": {

       “sub”:"248289761001”,

     }

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com"

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Comments:

Phil

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

---

From: Phil Hunt <[email-masked]>
Date: Wed, 1 Mar 2017 11:37:29 -0800

+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

> On Mar 1, 2017, at 11:20 AM, William Denniss <[email-masked]> wrote:
> 
> 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.
> 
> 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.
> 
> On Wed, Mar 1, 2017 at 10:27 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>>        "https://rp.example.com <https://rp.example.com/>"
>>      ],
>>      "events": {
>>          "iss":"https://connect.example.com <https://connect.example.com/>",
>>          "consentUri":[
>        "iss":"https://connect.example.com <https://connect.example.com/>”
>      }
>      "iat": 1458496025,
>        "https://rp.example.com <https://rp.example.com/>"
>      ],
>      "events": {
> *  in implicit federation (from RISC):   “uri”:”mailto:[email-masked] <mailto:[email-masked]>”
> *  in SCIM where resources have URIs:  “uri”:”https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 <https://scim.example.com/Users/44f6142df96bd6ab61e7521d9>"
> 
> [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, 1 Mar 2017 19:47:52 +0000

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:[email-masked]]
Sent: Wednesday, March 1, 2017 11:37 AM
To: William Denniss <[email-masked]>
Cc: Mike Jones <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Phil

On Mar 1, 2017, at 11:20 AM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

Two options:

1. Leave as is.

We currently have:

   {

     "sub": "248289761001",

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com<https://rp.example.com/>"

     ],

     "events": {

         "iss":"https://connect.example.com<https://connect.example.com/>",

         "consentUri":[

         ]

       }

     }

   }

Could be represented as:

   {

     “esub": {

       “sub”:"248289761001”,

       "iss":"https://connect.example.com<https://connect.example.com/>”

     }

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com<https://rp.example.com/>"

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Comments:

Phil

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Mar 2017 19:52:13 +0000

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:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, March 1, 2017 11:48 AM
To: Phil Hunt <[email-masked]>; William Denniss <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

                                                                -- Mike

From: Phil Hunt [mailto:[email-masked]]
Sent: Wednesday, March 1, 2017 11:37 AM
To: William Denniss <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Phil

Two options:

1. Leave as is.

We currently have:

   {

     "sub": "248289761001",

     "iat": 1458496025,

     "aud": [

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Could be represented as:

   {

     “esub": {

       “sub”:"248289761001”,

     }

     "iat": 1458496025,

     "aud": [

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Comments:

Phil

---

From: Phil Hunt <[email-masked]>
Date: Wed, 1 Mar 2017 11:56:24 -0800

Mike,

That’s somewhat true for Backchannel (see below).  In the RISC and SCIM cases it is only true 50% of the time — for example, RP initiated events stating that an IDP’s subject is showing suspicious activity or has been suspended at the relying party.  This is important to the IDP, because the account compromise may have began with the IDP.  OR, it may be that an session cookie was simply stolen and the IDP needs to reset the session.

Also, we’ve been talking about having RP initiated logout which is a user logging out of a specific application and we want to let the IDP know. The IDP then decides whether the logout is Single-Log-out or just RP specific.

Phil

> On Mar 1, 2017, at 11:47 AM, Mike Jones <[email-masked]> wrote:
> 
> www.independentid.com <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
>  
>  
> 
>  
> On Mar 1, 2017, at 11:20 AM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
>  
> www.independentid.com <http://www.independentid.com/>
> [email-masked] <mailto:[email-masked]>
>  
>  
>  
>  
>  
> 
>  
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 1 Mar 2017 11:57:12 -0800

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

Phil

> On Mar 1, 2017, at 11:52 AM, Mike Jones <[email-masked]> wrote:
> 
> From: Phil Hunt [mailto:[email-masked] <mailto:[email-masked]>] 
> To: William Denniss <[email-masked] <mailto:[email-masked]>>
> Cc: Mike Jones <[email-masked] <mailto:[email-masked]>>; ID Events Mailing List <[email-masked] <mailto:[email-masked]>>

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Mar 2017 12:06:15 -0800

On Wed, Mar 1, 2017 at 11:33 AM, Mike Jones <[email-masked]>
wrote:

> Hi William,
>
>
>
> I appreciate you supporting using the standard definitions for “sub” and
> “iss”.  That said, I then find it confusing that you are suggesting that
> people be prohibited from using “aud” (audience) in the standard way.
>
>
>
> I’ll also note that if you prohibit using “aud” in the standard way,
> you’ll both break the usage in the OpenID Connect Logout Token
> http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken
> and in SETs https://tools.ietf.org/html/draft-ietf-secevent-token-00#
> section-2.1.  Please let’s not go there.
>

I'm not suggesting an outright prohibition on "aud" being the client id, I
realise my words were a little inarticulate.

I see "aud as client id" as the domain of OpenID Connect (since that's
where that usage of "aud" was defined). I completely understand why Connect
Logout uses "aud as client id" and would expect other Connect specs to do
so – but these specs understand Connect and can be written to avoid
problems (as Logout does).

My guidence would be that a *non*-Connect specs should use "aud as URI"
(basically just !"aud as client id") to avoid accidently causing problems
for Connect.

When constrained that way, what do you think of the guidance?

Implementations using both ID Tokens and SETs can already unambiguously
> distinguish between them by the presence of the “events” claim.  ID Tokens
> don’t use “events” whereas SETs do.  The fact that “nonce” is present in an
> ID Token but not SETs provides an extra means of rejecting SETs in ID Token
> contexts.  I don’t see there as being any actual practical problem to solve
> that rises to the level of causing us to do unnatural things to claims
> usage.
>

+1

>
>
>                                                                 -- Mike
>
>
>
> *From:* William Denniss [mailto:[email-masked]]
> *Sent:* Wednesday, March 1, 2017 11:21 AM
> *To:* Phil Hunt <[email-masked]>; Mike Jones <
> [email-masked]>
> *Cc:* ID Events Mailing List <[email-masked]>
> *Subject:* Re: [Id-event] Thread: Clarifying use of sub and iss in SET
> tokens
>
>
>
> about I propose some new text for 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.
>
>
>
>
>
>
>

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Mar 2017 12:08:52 -0800

On Wed, Mar 1, 2017 at 11:47 AM, Mike Jones <[email-masked]>
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:[email-masked]]
> *Sent:* Wednesday, March 1, 2017 11:37 AM
> *To:* William Denniss <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; ID Events Mailing List <
> [email-masked]>
> 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
>
>
>
> about I propose some new text for https://tools.ietf.org/htm
> l/draft-ietf-secevent-token-00#section-3.5 capturing the "aud"

---

From: Mike Jones <[email-masked]>
Date: Wed, 1 Mar 2017 20:09:33 +0000

I suspect that lots of non-OpenID-Connect OAuth 2.0 use cases also use the Client ID as the Audience value, especially since some OAuth clients don’t even have a URL associated with them.  Trying to prohibit the use of Client IDs as audiences will likely break things that we’re not even aware of.

From: William Denniss [mailto:[email-masked]]
Sent: Wednesday, March 1, 2017 12:06 PM
To: Mike Jones <[email-masked]>
Cc: Phil Hunt <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

On Wed, Mar 1, 2017 at 11:33 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Hi William,

I'm not suggesting an outright prohibition on "aud" being the client id, I realise my words were a little inarticulate.

I see "aud as client id" as the domain of OpenID Connect (since that's where that usage of "aud" was defined). I completely understand why Connect Logout uses "aud as client id" and would expect other Connect specs to do so – but these specs understand Connect and can be written to avoid problems (as Logout does).

My guidence would be that a non-Connect specs should use "aud as URI" (basically just !"aud as client id") to avoid accidently causing problems for Connect.

+1

                                                                -- Mike

From: William Denniss [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 1, 2017 11:21 AM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Two options:

1. Leave as is.

We currently have:

   {

     "sub": "248289761001",

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com"

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Could be represented as:

   {

     “esub": {

       “sub”:"248289761001”,

     }

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com"

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Comments:

Phil

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Mar 2017 12:12:40 -0800

Seems to me that if you're using iss/aud in Connect you should be careful
in using that same iss/aud combination outside Connect.

What if the guidance is not an outright prohibition, but a security
consideration to "be careful", with a suggested mitigation (being not to
re-use iss/aud tuples outside of Connect).

On Wed, Mar 1, 2017 at 12:09 PM, Mike Jones <[email-masked]>
wrote:

> I suspect that lots of non-OpenID-Connect OAuth 2.0 use cases also use the
> Client ID as the Audience value, especially since some OAuth clients don’t
> even have a URL associated with them.  Trying to prohibit the use of Client
> IDs as audiences will likely break things that we’re not even aware of.
>
>
>
> *Sent:* Wednesday, March 1, 2017 12:06 PM
> *To:* Mike Jones <[email-masked]>
> *Cc:* Phil Hunt <[email-masked]>; ID Events Mailing List <
> [email-masked]>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 1 Mar 2017 12:28:40 -0800

We use it both ways. I would not use uri/url as a way to distinguish types. 

I think aud for logout is particularly important as it will often be identifying an SSO domain as well as a specific client id. 

Phil

> On Mar 1, 2017, at 12:12 PM, William Denniss <[email-masked]> wrote:
> 
> Seems to me that if you're using iss/aud in Connect you should be careful in using that same iss/aud combination outside Connect. 
> 
> What if the guidance is not an outright prohibition, but a security consideration to "be careful", with a suggested mitigation (being not to re-use iss/aud tuples outside of Connect).
> 
>> On Wed, Mar 1, 2017 at 12:09 PM, Mike Jones <[email-masked]> wrote:
>> On Wed, Mar 1, 2017 at 11:33 AM, Mike Jones <[email-masked]> wrote:
>> 
>> Hi William,
>> 
>>  
>> 
>> 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.  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 '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.
>> 
>>  
>>

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Mar 2017 12:44:52 -0800

OK so perhaps the "URI" thing is overly restrictive.

I guess the security consideration I'm recommending here is that you
shouldn't have multiple systems that issue JWTs with the same iss/aud
tuple, except when those systems are tightly coupled (as is the case with
Connect & Logout).

If a shared issuer is used, then URI-based namespacing is *one* way to
avoid this, but there are others.

I'm trying to avoid the need for SET to "break" possible use in access
tokens (one of the stated goals in the original post) – I think having
advice like this can avoid normative language that changes, and overly
complicates SET.

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 1 Mar 2017 15:54:56 -0800

We also talked about adding another claim that defines the type or purpose
of the JWT ("access token", "SET", etc). In a way it is the only sane
option, but it is not addressing existing implementations. Asking
implementors to "be careful" is asking for trouble IMO, especially because
systems evolve by incrementally adding functionality.

Marius

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Mar 2017 15:59:38 -0800

If JWT had a "typ" field all along, this entire discussion could be
avoided, but it's too late for that now. I believe that this was actually
the founding reason behind standardizing SET, introducing the "events"
claim. At least, to avoid the 3+ versions of event-on-JWT that were in
discussion at the time.

As with all security considerations people can not follow them and have bad
things happen.

Doesn't suggesting that unrelated systems not issue tokens sharing the same
iss/aud namespace make sense here as a mitigation though?  To me that's
better and more scalable than every spec removing some required claim from
the other specs (e.g. mandating that people can't use "sub").

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Mar 2017 00:03:32 +0000

Yes, adding another general-purpose JWT type claim was discussed on the mailing list.  My sense of that discussion was that people mostly agreed that doing that was new JWT work, and therefore in the scope of the OAuth working group, and not SecEvent-specific work, and so out of scope for the SecEvent working group.

If we write Security Considerations on the topic, they should be likewise scoped to use cases in which SETs are used, and not try to write new Security Considerations that apply to all JWTs.  Thus, it’s fine for the SET spec to say, for instance, that applications in which more than one kind of JWT can be signed by the same issuer, one kind of which is a SET, should take appropriate application-specific measures to ensure that the different kinds of JWTs cannot be confused for one another.  But beyond suggesting that these applications use the “events” claim to distinguish between SETs and other kinds of JWTs, trying to write specific general-purpose JWT guidance is out of scope for this working group.

                                                                -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Wednesday, March 1, 2017 3:55 PM
To: William Denniss <[email-masked]>
Cc: Phil Hunt (IDM) <[email-masked]>; Mike Jones <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

We also talked about adding another claim that defines the type or purpose of the JWT ("access token", "SET", etc). In a way it is the only sane option, but it is not addressing existing implementations. Asking implementors to "be careful" is asking for trouble IMO, especially because systems evolve by incrementally adding functionality.

Marius

On Wed, Mar 1, 2017 at 12:44 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:
OK so perhaps the "URI" thing is overly restrictive.

I guess the security consideration I'm recommending here is that you shouldn't have multiple systems that issue JWTs with the same iss/aud tuple, except when those systems are tightly coupled (as is the case with Connect & Logout).

If a shared issuer is used, then URI-based namespacing is *one* way to avoid this, but there are others.

I'm trying to avoid the need for SET to "break" possible use in access tokens (one of the stated goals in the original post) – I think having advice like this can avoid normative language that changes, and overly complicates SET.

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Mar 2017 00:07:21 +0000

Of course, there is already a “typ” claim.  Its use is optional, since whether it’s needed is application-specific.

Your suggestion that we issue general-purpose JWT guidance about iss/aud namespaces is exactly the kind of thing that’s beyond the scope of this working group, per my just-sent reply to Marius.  Suggesting that applications use the “events” claim to distinguish between SETs and other kinds of JWTs is within the scope of this working group, because it is advice about using SETs.

                                                       -- Mike

From: William Denniss [mailto:[email-masked]]
Sent: Wednesday, March 1, 2017 4:00 PM
To: Marius Scurtescu <[email-masked]>
Cc: Phil Hunt (IDM) <[email-masked]>; Mike Jones <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

If JWT had a "typ" field all along, this entire discussion could be avoided, but it's too late for that now. I believe that this was actually the founding reason behind standardizing SET, introducing the "events" claim. At least, to avoid the 3+ versions of event-on-JWT that were in discussion at the time.

As with all security considerations people can not follow them and have bad things happen.

Doesn't suggesting that unrelated systems not issue tokens sharing the same iss/aud namespace make sense here as a mitigation though?  To me that's better and more scalable than every spec removing some required claim from the other specs (e.g. mandating that people can't use "sub").

On Wed, Mar 1, 2017 at 3:54 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
We also talked about adding another claim that defines the type or purpose of the JWT ("access token", "SET", etc). In a way it is the only sane option, but it is not addressing existing implementations. Asking implementors to "be careful" is asking for trouble IMO, especially because systems evolve by incrementally adding functionality.

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 1 Mar 2017 16:21:39 -0800

As a concrete example, let's say an RP that supports OIDC decides to also
implement RISC/SET. When they read the spec and decide on implementation
they realize that they also have to modify the existing OIDC implementation
so it does not accept Id Token looking JWTs that have an "events" claim. It
is very easy to miss this requirement. But more important, when the next
JWT application is implemented they might have to yet again update the
existing OIDC implementation, and so forth.

One simpler fix would be to modify the OIDC implementation once to look for
the correct "typ" claim (assuming one is defined). The security
considerations in the SET spec could specify that due to iss/aud overlap it
is crucial that typ is validated in all related implementations.

I understand that typ cannot be standardized by the SET spec for other
specs (but it could definitely clearly define it for SET), but I think the
sooner we do that for all relevant specs the better.

Marius

On Wed, Mar 1, 2017 at 4:07 PM, Mike Jones <[email-masked]>
wrote:

> Of course, there is already a “typ” claim.  Its use is optional, since
> whether it’s needed is application-specific.
>
>
>
> Your suggestion that we issue general-purpose JWT guidance about iss/aud
> namespaces is exactly the kind of thing that’s beyond the scope of this
> working group, per my just-sent reply to Marius.  Suggesting that
> applications use the “events” claim to distinguish between SETs and other
> kinds of JWTs is within the scope of this working group, because it is
> advice about using SETs.
>
>
>
>                                                        -- Mike
>
>
>
> *Sent:* Wednesday, March 1, 2017 4:00 PM
> *To:* Marius Scurtescu <[email-masked]>
> *Cc:* Phil Hunt (IDM) <[email-masked]>; Mike Jones <
> [email-masked]>; ID Events Mailing List <[email-masked]>
> Doesn't suggesting that unrelated systems not issue tokens sharing the
> same iss/aud namespace make sense here as a mitigation though?  To me
> that's better and more scalable than every spec removing some required
> claim from the other specs (e.g. mandating that people can't use "sub").
>
>
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 2 Mar 2017 00:31:00 +0000

Except that your example isn’t one in which there’s an actual problem.  For all response_types except for “code”, the ID Token must have a “nonce” claim matching the request in order to be validated.  SETs won’t have this claim.  For response_type=code, the ID Token must be retrieved from the Token Endpoint to be valid.  But SETs aren’t returned as the id_token value from the Token Endpoint.  There isn’t a channel in which an attacker can successfully substitute a SET for an ID Token and have it validate as an ID Token.

Following the advice to also verify that there isn’t an “events” claim in an ID Token provides redundancy and is good hygiene but isn’t actually even necessary to prevent substitution attacks.

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Wednesday, March 1, 2017 4:22 PM
To: Mike Jones <[email-masked]>
Cc: William Denniss <[email-masked]>; Phil Hunt (IDM) <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

As a concrete example, let's say an RP that supports OIDC decides to also implement RISC/SET. When they read the spec and decide on implementation they realize that they also have to modify the existing OIDC implementation so it does not accept Id Token looking JWTs that have an "events" claim. It is very easy to miss this requirement. But more important, when the next JWT application is implemented they might have to yet again update the existing OIDC implementation, and so forth.

One simpler fix would be to modify the OIDC implementation once to look for the correct "typ" claim (assuming one is defined). The security considerations in the SET spec could specify that due to iss/aud overlap it is crucial that typ is validated in all related implementations.

I understand that typ cannot be standardized by the SET spec for other specs (but it could definitely clearly define it for SET), but I think the sooner we do that for all relevant specs the better.

Marius

On Wed, Mar 1, 2017 at 4:07 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Of course, there is already a “typ” claim.  Its use is optional, since whether it’s needed is application-specific.

                                                       -- Mike

From: William Denniss [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 1, 2017 4:00 PM
To: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 1 Mar 2017 16:36:12 -0800

Mike, me providing a bulletproof example is irrelevant I think. I am trying
to convey a general idea. My point is that having to continuously update
existing implementations with new validation rules is error prone and less
likely to happen that having to do one generic update.

Marius

On Wed, Mar 1, 2017 at 4:31 PM, Mike Jones <[email-masked]>
wrote:

> Except that your example isn’t one in which there’s an actual problem.
> For all response_types except for “code”, the ID Token must have a “nonce”
> claim matching the request in order to be validated.  SETs won’t have this
> claim.  For response_type=code, the ID Token must be retrieved from the
> Token Endpoint to be valid.  But SETs aren’t returned as the id_token value
> from the Token Endpoint.  There isn’t a channel in which an attacker can
> successfully substitute a SET for an ID Token and have it validate as an ID
> Token.
>
>
>
> Following the advice to also verify that there isn’t an “events” claim in
> an ID Token provides redundancy and is good hygiene but isn’t actually even
> necessary to prevent substitution attacks.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Marius Scurtescu [mailto:[email-masked]]
> *Sent:* Wednesday, March 1, 2017 4:22 PM
> *Cc:* William Denniss <[email-masked]>; Phil Hunt (IDM) <
> [email-masked]>; ID Events Mailing List <[email-masked]>
>
> One simpler fix would be to modify the OIDC implementation once to look
> for the correct "typ" claim (assuming one is defined). The security

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Mar 2017 16:50:02 -0800

> existing OIDC implementation, and so forth.

Why would the RISC implementation reuse the same iss/aud pair as the OIDC
implementation?

If it didn't, there's no issue! Isn't this the simplest approach? Given
that "typ" isn't mandated by JWT, I think that this is therefore the
implied method for segregating JWTs by the usage intent.

On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <[email-masked]>
wrote:

> Mike, me providing a bulletproof example is irrelevant I think. I am
> trying to convey a general idea. My point is that having to continuously
> update existing implementations with new validation rules is error prone
> and less likely to happen that having to do one generic update.
>
> Marius
>
>> We also talked about adding another claim that defines the type or
>> purpose of the JWT ("access token", "SET", etc). In a way it is the only
>> sane option, but it is not addressing existing implementations. Asking

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 1 Mar 2017 17:05:09 -0800

> Why would the RISC implementation reuse the same iss/aud pair as the OIDC

iss naturally would be the same in most cases. I would argue that aud would
also naturally be the same, the client id, since that is the intended
recipient. Having aud be the URL of the target endpoint for example (the
only suggestion I am aware of), is hackish at best. The same endpoint could
be shared by multiple clients in some cases. Also, this couples creating
the SET with delivery details

> If it didn't, there's no issue!
>

There might be no issue for SET, but we are going to run into this problem
over and over again.

> Isn't this the simplest approach? Given that "typ" isn't mandated by JWT,
> I think that this is therefore the implied method for segregating JWTs by
> the usage intent.
>

Not sure what you mean by "this". Replacing typ with unique iss/aud
combinations?

>>> Following the advice to also verify that there isn’t an “events” claim
>>> in an ID Token provides redundancy and is good hygiene but isn’t actually
>>> even necessary to prevent substitution attacks.
>>>
>>>
>>>
>>>                                                        -- Mike
>>>
>>>
>>>
>>> As a concrete example, let's say an RP that supports OIDC decides to
>>> also implement RISC/SET. When they read the spec and decide on
>>> implementation they realize that they also have to modify the existing OIDC
>>> implementation so it does not accept Id Token looking JWTs that have an
>>> "events" claim. It is very easy to miss this requirement. But more
>>> important, when the next JWT application is implemented they might have to
>>> yet again update the existing OIDC implementation, and so forth.
>>>
>>>
>>>

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Mar 2017 17:30:25 -0800

On Wed, Mar 1, 2017 at 5:05 PM, Marius Scurtescu <[email-masked]>
wrote:

> iss naturally would be the same in most cases. I would argue that aud
> would also naturally be the same, the client id, since that is the intended

Why not change iss for RISC?  https://issuer.google.com/risc for example.

> Not sure what you mean by "this". Replacing typ with unique iss/aud

Our issue is that we have a common token format JWT, that multiple systems
will consume which have different concerns.  Reading RFC7519, I don't see
any way to separate those concerns, other than with iss/aud.  RFC7519
doesn't say "each spec that uses JWT should use a unique combination of
claims such at no other spec could accidently interpret it as meant for
them" (and I'm not convinced this is scalable, or desirable).  Nor does it
require the use of a type claim to achieve the usage segregation, and it's
too late to add one now.

>>>> Your suggestion that we issue general-purpose JWT guidance about
>>>> iss/aud namespaces is exactly the kind of thing that’s beyond the scope of
>>>> this working group, per my just-sent reply to Marius.  Suggesting that
>>>> [email-masked]>; ID Events Mailing List <[email-masked]
>>>> >

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 1 Mar 2017 17:52:49 -0800

On Wed, Mar 1, 2017 at 5:30 PM, William Denniss <[email-masked]> wrote:

>>> Why would the RISC implementation reuse the same iss/aud pair as the
>>> OIDC implementation?
>>>
>>

Because iss/sub basically forces the iss to be the exact same as in the Id
Token. And separate iss requires separate signing keys.

>> There might be no issue for SET, but we are going to run into this
>> problem over and over again.
>>
>>
>>
>>> Isn't this the simplest approach? Given that "typ" isn't mandated by
>>> JWT, I think that this is therefore the implied method for segregating JWTs
>>> by the usage intent.
>>>
>>

I totally agree that we have no ideal solution here. Having each
application define its own URN (or some schema) for aud might work, even if
ugly. This is similar to merging typ into aud. Do we have any concrete
proposals here?

Why is it too late to use typ?

>>>> On Wed, Mar 1, 2017 at 4:31 PM, Mike Jones <[email-masked]
>>>> > wrote:
>>>>
>>>>> Except that your example isn’t one in which there’s an actual
>>>>> problem.  For all response_types except for “code”, the ID Token must have
>>>>> a “nonce” claim matching the request in order to be validated.  SETs won’t
>>>>> have this claim.  For response_type=code, the ID Token must be retrieved
>>>>> from the Token Endpoint to be valid.  But SETs aren’t returned as the
>>>>> id_token value from the Token Endpoint.  There isn’t a channel in which an
>>>>> attacker can successfully substitute a SET for an ID Token and have it
>>>>> validate as an ID Token.
>>>>>
>>>>>
>>>>>
>>>>> *Subject:* Re: [Id-event] Thread: Clarifying use of sub and iss in
>>>>> SET tokens
>>>>>
>>>>>
>>>>>
>>>>> One simpler fix would be to modify the OIDC implementation once to
>>>>> look for the correct "typ" claim (assuming one is defined). The security
>>>>> On Wed, Mar 1, 2017 at 4:07 PM, Mike Jones <
>>>>> [email-masked]> wrote:
>>>>>
>>>>> *Subject:* Re: [Id-event] Thread: Clarifying use of sub and iss in
>>>>> SET tokens
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 1, 2017 at 3:54 PM, Marius Scurtescu <
>>>>> [email-masked]> wrote:
>>>>>

---

From: William Denniss <[email-masked]>
Date: Wed, 1 Mar 2017 18:05:37 -0800

> Token. And separate iss requires separate signing keys.

We'd have to host the keys multiple times, but they *could* still be the
same keys, right?

>> Our issue is that we have a common token format JWT, that multiple
>> systems will consume which have different concerns.  Reading RFC7519, I
>> don't see any way to separate those concerns, other than with iss/aud.
>> RFC7519 doesn't say "each spec that uses JWT should use a unique
>> combination of claims such at no other spec could accidently interpret it
>> as meant for them" (and I'm not convinced this is scalable, or desirable).
>> Nor does it require the use of a type claim to achieve the usage
>> segregation, and it's too late to add one now.
>>
>

Defining a structured aud format could solve this, I agree – like you say,
it's merging type into aud in a way that's backwards compatible.
Personally I don't mind that approach, but I recall some resistance to it.

Some kind of separation based on iss or aud I think is going to be the
safest and most scalable solution.

Because of all the clients already written that don't check for it.

>
>>
>>>
>>>>
>>>> On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <[email-masked]
>>>> > wrote:
>>>>
>>>>> On Wed, Mar 1, 2017 at 4:31 PM, Mike Jones <
>>>>>> Following the advice to also verify that there isn’t an “events”
>>>>>> claim in an ID Token provides redundancy and is good hygiene but isn’t
>>>>>> actually even necessary to prevent substitution attacks.
>>>>>>
>>>>>>
>>>>>>
>>>>>>                                                        -- Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> I understand that typ cannot be standardized by the SET spec for
>>>>>> other specs (but it could definitely clearly define it for SET), but I
>>>>>> think the sooner we do that for all relevant specs the better.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Marius
>>>>>>
>>>>>>
>>>>>>
>>>>>> Of course, there is already a “typ” claim.  Its use is optional,
>>>>>> since whether it’s needed is application-specific.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Doesn't suggesting that unrelated systems not issue tokens sharing
>>>>>> the same iss/aud namespace make sense here as a mitigation though?  To me
>>>>>> I'm trying to avoid the need for SET to "break" possible use in
>>>>>> access tokens (one of the stated goals in the original post) – I think
>>>>>> having advice like this can avoid normative language that changes, and
>>>>>> overly complicates SET.
>>>>>>
>>>>>>
>>>>>>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 2 Mar 2017 08:53:00 -0700

Not that it makes a difference helping the situation here but "typ" is a
JOSE header rather than a JWT claim (see https://tools.ietf.org/html/
rfc7515#section-4.1.9 and https://tools.ietf.org/html/rfc7516#section-4.1.11
and https://tools.ietf.org/html/rfc7519#section-5.1).

That got me thinking, however, that maybe the "crit" JOSE header (
https://tools.ietf.org/html/rfc7515#section-4.1.11) might be useful here.
Assuming JWT/JOSE implementations support "crit" per spec (they *should*
but that might be an optimistic assumption) then it could be used to
address the 'clients already written that don't check for it' problem.
Something like a new "set" header that gets marked as critical. I.e. as
just a strawman,

     {
      "alg":"ES256",
      "crit":["set"],
      "set":true
     }

says that the receiver must understand and process the "set" header, which
existing OIDC and OAuth JWT consumers wouldn't.

Honestly not sure if that's a good idea or not. But wanted to throw it out
there.

On Wed, Mar 1, 2017 at 7:05 PM, William Denniss <[email-masked]> wrote:

>> Because iss/sub basically forces the iss to be the exact same as in the
>> Id Token. And separate iss requires separate signing keys.
>>
>
>>>>> On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <
>>>>>>> On Wed, Mar 1, 2017 at 12:44 PM, William Denniss <
>>>>>>> [email-masked]> wrote:
>>>>>>>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 2 Mar 2017 08:03:12 -0800

Interesting!  +1

Phil

> On Mar 2, 2017, at 7:53 AM, Brian Campbell <[email-masked]> wrote:
> 
> Not that it makes a difference helping the situation here but "typ" is a JOSE header rather than a JWT claim (see https://tools.ietf.org/html/rfc7515#section-4.1.9 <https://tools.ietf.org/html/rfc7515#section-4.1.9> and https://tools.ietf.org/html/rfc7516#section-4.1.11 <https://tools.ietf.org/html/rfc7516#section-4.1.11> and https://tools.ietf.org/html/rfc7519#section-5.1 <https://tools.ietf.org/html/rfc7519#section-5.1>).
> 
> That got me thinking, however, that maybe the "crit" JOSE header (https://tools.ietf.org/html/rfc7515#section-4.1.11 <https://tools.ietf.org/html/rfc7515#section-4.1.11>) might be useful here. Assuming JWT/JOSE implementations support "crit" per spec (they *should* but that might be an optimistic assumption) then it could be used to address the 'clients already written that don't check for it' problem. Something like a new "set" header that gets marked as critical. I.e. as just a strawman, 
> 
>      {
>       "alg":"ES256",
>       "crit":["set"],
>       "set":true
>      }
> says that the receiver must understand and process the "set" header, which existing OIDC and OAuth JWT consumers wouldn't. 
> 
> Honestly not sure if that's a good idea or not. But wanted to throw it out there.  
> 
> 
> 
> 
> 
> On Wed, Mar 1, 2017 at 7:05 PM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> On Wed, Mar 1, 2017 at 5:52 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Mar 1, 2017 at 5:30 PM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Wed, Mar 1, 2017 at 5:05 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
> On Wed, Mar 1, 2017 at 4:50 PM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
> Why would the RISC implementation reuse the same iss/aud pair as the OIDC implementation?
> 
> iss naturally would be the same in most cases. I would argue that aud would also naturally be the same, the client id, since that is the intended recipient. Having aud be the URL of the target endpoint for example (the only suggestion I am aware of), is hackish at best. The same endpoint could be shared by multiple clients in some cases. Also, this couples creating the SET with delivery details
> 
> Why not change iss for RISC?  https://issuer.google.com/risc <https://issuer.google.com/risc> for example.
> 
> Because iss/sub basically forces the iss to be the exact same as in the Id Token. And separate iss requires separate signing keys.
> 
> We'd have to host the keys multiple times, but they *could* still be the same keys, right?
>  
> 
> There might be no issue for SET, but we are going to run into this problem over and over again.
> 
>  
> Isn't this the simplest approach? Given that "typ" isn't mandated by JWT, I think that this is therefore the implied method for segregating JWTs by the usage intent.
> 
> Not sure what you mean by "this". Replacing typ with unique iss/aud combinations?
> 
> Our issue is that we have a common token format JWT, that multiple systems will consume which have different concerns.  Reading RFC7519, I don't see any way to separate those concerns, other than with iss/aud.  RFC7519 doesn't say "each spec that uses JWT should use a unique combination of claims such at no other spec could accidently interpret it as meant for them" (and I'm not convinced this is scalable, or desirable).  Nor does it require the use of a type claim to achieve the usage segregation, and it's too late to add one now.
> 
> I totally agree that we have no ideal solution here. Having each application define its own URN (or some schema) for aud might work, even if ugly. This is similar to merging typ into aud. Do we have any concrete proposals here?
> 
> Defining a structured aud format could solve this, I agree – like you say, it's merging type into aud in a way that's backwards compatible.  Personally I don't mind that approach, but I recall some resistance to it.
> 
> Some kind of separation based on iss or aud I think is going to be the safest and most scalable solution. 
> 
> On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
> Mike, me providing a bulletproof example is irrelevant I think. I am trying to convey a general idea. My point is that having to continuously update existing implementations with new validation rules is error prone and less likely to happen that having to do one generic update.
> 
> Marius
> 
> On Wed, Mar 1, 2017 at 4:31 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>   <>
> From: Marius Scurtescu [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: William Denniss <[email-masked] <mailto:[email-masked]>>; Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>>; ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> 
> 
> On Wed, Mar 1, 2017 at 4:07 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> 
>   <>
> From: William Denniss [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
> Cc: Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>>; Mike Jones <[email-masked] <mailto:[email-masked]>>; ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> On Wed, Mar 1, 2017 at 3:54 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Wed, Mar 1, 2017 at 12:44 PM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 2 Mar 2017 08:05:55 -0800

PS.  This is another of Yaron’s threads….”Avoiding SETS being confused as access tokens”

Phil

> On Mar 2, 2017, at 8:03 AM, Phil Hunt <[email-masked]> wrote:
> 
> Interesting!  +1
> 
> Phil
> 
>> On Mar 2, 2017, at 7:53 AM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 2 Mar 2017 16:34:51 -0800

I did not realize that typ is a header. Shouldn't ideally the SET purpose
or "type" be a claim rather?

I doubt that any existing libraries take crit into account. Can anyone
point to a library that does look at crit? With that in mind, crit does not
help much IMO, we might just as well define a type claim.

Marius

On Thu, Mar 2, 2017 at 8:05 AM, Phil Hunt <[email-masked]> wrote:

> JOSE header rather than a JWT claim (see https://tools.ietf.org/html/rf
> c7515#section-4.1.9 and https://tools.ietf.org/html/rfc7516#section-4.1.11
>>>> On Wed, Mar 1, 2017 at 5:05 PM, Marius Scurtescu <[email-masked]
>>>> > wrote:
>>>>
>> Defining a structured aud format could solve this, I agree – like you
>> say, it's merging type into aud in a way that's backwards compatible.
>>>>>>>> As a concrete example, let's say an RP that supports OIDC decides
>>>>>>>> to also implement RISC/SET. When they read the spec and decide on
>>>>>>>> I guess the security consideration I'm recommending here is that
>>>>>>>> you shouldn't have multiple systems that issue JWTs with the same iss/aud

---

From: Mike Jones <[email-masked]>
Date: Fri, 3 Mar 2017 02:12:03 +0000

It’s not a legal JWT implementation if it doesn’t implement “crit”.  Per https://tools.ietf.org/html/rfc7515#section-4.1.11, “This Header Parameter MUST be understood and processed by implementations”.  If you know of implementations that don’t support it, we should lobby to get them fixed, rather than trying to work around bugs in those implementations.

Again, doing general-purpose JWT work is not in the scope of this working group.  (The OAuth WG owns that.)  Doing SecEvent-specific JWT work is in scope.

                                                                -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Thursday, March 2, 2017 4:35 PM
To: Phil Hunt <[email-masked]>
Cc: Brian Campbell <[email-masked]>; William Denniss <[email-masked]>; Mike Jones <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: Clarifying use of sub and iss in SET tokens)

I did not realize that typ is a header. Shouldn't ideally the SET purpose or "type" be a claim rather?

I doubt that any existing libraries take crit into account. Can anyone point to a library that does look at crit? With that in mind, crit does not help much IMO, we might just as well define a type claim.

Marius

On Thu, Mar 2, 2017 at 8:05 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
PS.  This is another of Yaron’s threads….”Avoiding SETS being confused as access tokens”

Phil

On Mar 2, 2017, at 8:03 AM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:

Interesting!  +1

Phil

On Mar 2, 2017, at 7:53 AM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Not that it makes a difference helping the situation here but "typ" is a JOSE header rather than a JWT claim (see https://tools.ietf.org/html/rfc7515#section-4.1.9 and https://tools.ietf.org/html/rfc7516#section-4.1.11 and https://tools.ietf.org/html/rfc7519#section-5.1).
That got me thinking, however, that maybe the "crit" JOSE header (https://tools.ietf.org/html/rfc7515#section-4.1.11) might be useful here. Assuming JWT/JOSE implementations support "crit" per spec (they *should* but that might be an optimistic assumption) then it could be used to address the 'clients already written that don't check for it' problem. Something like a new "set" header that gets marked as critical. I.e. as just a strawman,

     {
      "alg":"ES256",

      "crit":["set"],

      "set":true

     }

On Wed, Mar 1, 2017 at 7:05 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Mar 1, 2017 at 5:52 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Mar 1, 2017 at 5:30 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Mar 1, 2017 at 5:05 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, Mar 1, 2017 at 4:50 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:
As a concrete example, let's say an RP that supports OIDC decides to also implement RISC/SET. When they read the spec and decide on implementation they realize that they also have to modify the existing OIDC implementation so it does not accept Id Token looking JWTs that have an "events" claim. It is very easy to miss this requirement. But more important, when the next JWT application is implemented they might have to yet again update the existing OIDC implementation, and so forth.

On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
Mike, me providing a bulletproof example is irrelevant I think. I am trying to convey a general idea. My point is that having to continuously update existing implementations with new validation rules is error prone and less likely to happen that having to do one generic update.

Marius

On Wed, Mar 1, 2017 at 4:31 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Except that your example isn’t one in which there’s an actual problem.  For all response_types except for “code”, the ID Token must have a “nonce” claim matching the request in order to be validated.  SETs won’t have this claim.  For response_type=code, the ID Token must be retrieved from the Token Endpoint to be valid.  But SETs aren’t returned as the id_token value from the Token Endpoint.  There isn’t a channel in which an attacker can successfully substitute a SET for an ID Token and have it validate as an ID Token.

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, March 1, 2017 4:22 PM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: William Denniss <[email-masked]<mailto:[email-masked]>>; Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>

Marius

                                                       -- Mike

Marius

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 2 Mar 2017 18:17:21 -0800

On Thu, Mar 2, 2017 at 6:12 PM, Mike Jones <[email-masked]>
wrote:

> It’s not a legal JWT implementation if it doesn’t implement “crit”.  Per
> https://tools.ietf.org/html/rfc7515#section-4.1.11, “This Header
> Parameter MUST be understood and processed by implementations”.  If you
> know of implementations that don’t support it, we should lobby to get them
> fixed, rather than trying to work around bugs in those implementations.
>

Thanks for clarifying. Then Brian's proposal is definitely viable.

>
>
> Again, doing general-purpose JWT work is not in the scope of this working
> group.  (The OAuth WG owns that.)  Doing SecEvent-specific JWT work is in
> scope.
>

I totally understand that Mike, but to me it looked like there is no good
solution in scope for this working group, so I suggested we escalate.

> *Sent:* Thursday, March 2, 2017 4:35 PM
> *To:* Phil Hunt <[email-masked]>
> *Cc:* Brian Campbell <[email-masked]>; William Denniss <
> [email-masked]>; Mike Jones <[email-masked]>; ID Events
> Mailing List <[email-masked]>
> *Subject:* Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread:
> Clarifying use of sub and iss in SET tokens)
>
>
>
> rfc7515#section-4.1.9 and https://tools.ietf.org/html/
> rfc7516#section-4.1.11 and https://tools.ietf.org/html/rfc7519#section-5.1
> ).
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 3 Mar 2017 07:03:14 -0700

Understanding and processing "crit" is a normative MUST in a published RFC
so *surely* all JWT/JOSE libraries dutifully implement support for it,
right? Right? Right?

The open source JWT/JOSE library that I've build
<https://bitbucket.org/b_c/jose4j/wiki/Home> does understand the "crit"
header. So there's one data point. But it may not be representative of the
broader world of implementations out there.

The requirements around "crit" are somewhat esoteric and it's not something
that's needed to just get happy path JWT stuff working. So, despite being a
MUST, it'd wouldn't be surprising if support for it in the wild was spotty.
How much should theoretical (but likely) implementation defects play into
protocol design? I don't know the answer. It would be nice to rely on the
requirements of the RFC 7515-7519 group and, as Mike suggests, push to get
deficient implementations fixed. But practically speaking that might amount
to willful ignorance.

On Thu, Mar 2, 2017 at 7:17 PM, Marius Scurtescu <[email-masked]>
wrote:

>> [email-masked]>; Mike Jones <[email-masked]>; ID
>> Events Mailing List <[email-masked]>
>> c7515#section-4.1.9 and https://tools.ietf.org/html/rf
>> c7516#section-4.1.11 and https://tools.ietf.org/html/rfc7519#section-5.1
>> ).
>>
>> https://tools.ietf.org/html/rfc7515#section-4.1.11) might be useful
>> here. Assuming JWT/JOSE implementations support "crit" per spec (they
>> *should* but that might be an optimistic assumption) then it could be used
>> to address the 'clients already written that don't check for it' problem.
>> says that the receiver must understand and process the "set" header,
>> which existing OIDC and OAuth JWT consumers wouldn't.
>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 Mar 2017 11:00:30 -0600

On 03/03/2017 08:03 AM, Brian Campbell wrote:
> How much should theoretical (but likely) implementation defects play
> into protocol design? I don't know the answer. It would be nice to
> rely on the requirements of the RFC 7515-7519 group and, as Mike
> suggests, push to get deficient implementations fixed. But practically
> speaking that might amount to willful ignorance.

When possible, protocol designs can allow for well-behaved ecosystem
participants to enforce the behavior in question, as in TLS's GREASE to
detect intolerance to adding new codepoints in various fields.
And of course, making the required behavior critical for normal
functionality is a good way to get it implemented everywhere, but that's
not really an answer so much as an observation.

-Ben

---

From: Vivek Biswas <[email-masked]>
Date: Fri, 3 Mar 2017 10:22:41 -0800 (PST)

I am not a big fan of defining type within the header field of the JWT since the header field is not signed and decisions can be influenced by doing MIM attacks.

See article

https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/

This attack is also known as “"Algorithm choice as an attack vector"

Similar attack can be done with respect to the “type”.

If a type is required it should be defined within the body which is signed.

Regards

Vivek Biswas, CISSP

Consulting Member @Security

Oracle Corporation, San Jose

From: Marius Scurtescu [mailto:[email-masked]] 
Sent: Thursday, March 02, 2017 6:17 PM
To: Mike Jones
Cc: William Denniss; Brian Campbell; ID Events Mailing List; Phil Hunt
Subject: Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: Clarifying use of sub and iss in SET tokens)

On Thu, Mar 2, 2017 at 6:12 PM, Mike Jones <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

I totally understand that Mike, but to me it looked like there is no good solution in scope for this working group, so I suggested we escalate.

                                                                -- Mike

From: Marius Scurtescu [mailto:HYPERLINK "mailto:[email-masked]"[email-masked]] 
Sent: Thursday, March 2, 2017 4:35 PM
To: Phil Hunt <HYPERLINK "mailto:[email-masked]"[email-masked]>
Cc: Brian Campbell <HYPERLINK "mailto:[email-masked]"[email-masked]>; William Denniss <HYPERLINK "mailto:[email-masked]"[email-masked]>; Mike Jones <HYPERLINK "mailto:[email-masked]"[email-masked]>; ID Events Mailing List <HYPERLINK "mailto:[email-masked]"[email-masked]>
Subject: Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: Clarifying use of sub and iss in SET tokens)

Marius

On Thu, Mar 2, 2017 at 8:05 AM, Phil Hunt <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

 

Phil

@independentid

HYPERLINK "http://www.independentid.com"www.independentid.com

HYPERLINK "mailto:[email-masked]"[email-masked]

 

On Mar 2, 2017, at 8:03 AM, Phil Hunt <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

Interesting!  +1

Phil

@independentid

HYPERLINK "http://www.independentid.com/"www.independentid.com

HYPERLINK "mailto:[email-masked]"[email-masked]

 

On Mar 2, 2017, at 7:53 AM, Brian Campbell <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

     {
      "alg":"ES256",
      "crit":["set"],
      "set":true
     }

 

On Wed, Mar 1, 2017 at 7:05 PM, William Denniss <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

On Wed, Mar 1, 2017 at 5:52 PM, Marius Scurtescu <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

On Wed, Mar 1, 2017 at 5:30 PM, William Denniss <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

On Wed, Mar 1, 2017 at 5:05 PM, Marius Scurtescu <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

On Wed, Mar 1, 2017 at 4:50 PM, William Denniss <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

 

 

 

On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

Marius

On Wed, Mar 1, 2017 at 4:31 PM, Mike Jones <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

                                                       -- Mike

From: Marius Scurtescu [mailto:HYPERLINK "mailto:[email-masked]"[email-masked]] 
Sent: Wednesday, March 1, 2017 4:22 PM
To: Mike Jones <HYPERLINK "mailto:[email-masked]"[email-masked]>
Cc: William Denniss <HYPERLINK "mailto:[email-masked]"[email-masked]>; Phil Hunt (IDM) <HYPERLINK "mailto:[email-masked]"[email-masked]>; ID Events Mailing List <HYPERLINK "mailto:[email-masked]"[email-masked]>

 

 

Marius

On Wed, Mar 1, 2017 at 4:07 PM, Mike Jones <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

                                                       -- Mike

From: William Denniss [mailto:HYPERLINK "mailto:[email-masked]"[email-masked]] 
Sent: Wednesday, March 1, 2017 4:00 PM
To: Marius Scurtescu <HYPERLINK "mailto:[email-masked]"[email-masked]>
Cc: Phil Hunt (IDM) <HYPERLINK "mailto:[email-masked]"[email-masked]>; Mike Jones <HYPERLINK "mailto:[email-masked]"[email-masked]>; ID Events Mailing List <HYPERLINK "mailto:[email-masked]"[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

 

On Wed, Mar 1, 2017 at 3:54 PM, Marius Scurtescu <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

Marius

On Wed, Mar 1, 2017 at 12:44 PM, William Denniss <HYPERLINK "mailto:[email-masked]"[email-masked]> wrote:

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

 

 

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

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

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

---

From: Brian Campbell <[email-masked]>
Date: Fri, 3 Mar 2017 15:32:35 -0700

The JWT/JWS header is covered by the signature.

On Fri, Mar 3, 2017 at 11:22 AM, Vivek Biswas <[email-masked]>
wrote:

> I am not a big fan of defining type within the header field of the JWT
> since the header field is not signed and decisions can be influenced by
> doing MIM attacks.
>
>
>
> See article
>
> *Sent:* Thursday, March 02, 2017 6:17 PM
> *To:* Mike Jones
> *Cc:* William Denniss; Brian Campbell; ID Events Mailing List; Phil Hunt
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Fri, 3 Mar 2017 15:34:18 -0800

Would we want to make signing mandatory to ensure SET differentiation is protected (in addition to the other benefits)?

Phil

> On Mar 3, 2017, at 2:32 PM, Brian Campbell <[email-masked]> wrote:
> 
>> On Fri, Mar 3, 2017 at 11:22 AM, Vivek Biswas <[email-masked]> wrote:
>> On Thu, Mar 2, 2017 at 6:12 PM, Mike Jones <[email-masked]> wrote:
>> 
>> On Wed, Mar 1, 2017 at 5:52 PM, Marius Scurtescu <[email-masked]> wrote:
>> 
>> On Wed, Mar 1, 2017 at 5:05 PM, Marius Scurtescu <[email-masked]> wrote:
>> 
>> On Wed, Mar 1, 2017 at 4:36 PM, Marius Scurtescu <[email-masked]> wrote:
>> 
>> On Wed, Mar 1, 2017 at 4:31 PM, Mike Jones <[email-masked]> wrote:
>> 
>> On Wed, Mar 1, 2017 at 4:07 PM, Mike Jones <[email-masked]> wrote:
>> 
>> On Wed, Mar 1, 2017 at 3:54 PM, Marius Scurtescu <[email-masked]> wrote:
>> 
>> On Wed, Mar 1, 2017 at 12:44 PM, William Denniss <[email-masked]> wrote:
>>

---

From: Mike Jones <[email-masked]>
Date: Sat, 4 Mar 2017 00:48:36 +0000

That’s another issue that’s already been well-discussed.  There are plenty of cases in which “alg”: “none” is the right level of integrity protection for JWTs – including SETs.  This is the case when, for instance, the JWT or SET is already integrity protected by the transport – such as TLS.  We should definitely leave the choice of JWT/SET algorithms up to the application – just like the base JWT spec did.

I understand the urge to “tighten things up” but it’s often the case when we “tighten things up” we’d be imposing restrictions on SETs that would make them a poor match for particular use cases, causing them to not use SETs at all.  The value of SETs is that they define an “events” claim and its usage within JWTs.  Unless there are compelling reasons to go further, we should stop there and declare victory.

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Friday, March 3, 2017 3:34 PM
To: Brian Campbell <[email-masked]>
Cc: Vivek Biswas <[email-masked]>; Marius Scurtescu <[email-masked]>; Mike Jones <[email-masked]>; William Denniss <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: Clarifying use of sub and iss in SET tokens)

Phil

On Mar 3, 2017, at 2:32 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
The JWT/JWS header is covered by the signature.

On Fri, Mar 3, 2017 at 11:22 AM, Vivek Biswas <[email-masked]<mailto:[email-masked]>> wrote:
I am not a big fan of defining type within the header field of the JWT since the header field is not signed and decisions can be influenced by doing MIM attacks.

See article

Regards
Vivek Biswas, CISSP

On Thu, Mar 2, 2017 at 6:12 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
It’s not a legal JWT implementation if it doesn’t implement “crit”.  Per https://tools.ietf.org/html/rfc7515#section-4.1.11, “This Header Parameter MUST be understood and processed by implementations”.  If you know of implementations that don’t support it, we should lobby to get them fixed, rather than trying to work around bugs in those implementations.

                                                                -- Mike

From: Marius Scurtescu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, March 2, 2017 4:35 PM
To: Phil Hunt <[email-masked]<mailto:[email-masked]>>
Cc: Brian Campbell <[email-masked]<mailto:[email-masked]>>; William Denniss <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Making SETs distinct as JWTs (was: Re: Thread: Clarifying use of sub and iss in SET tokens)

Marius

Phil

Interesting!  +1

Phil

     {
      "alg":"ES256",

      "crit":["set"],

      "set":true

     }

Marius

                                                       -- Mike

Marius

                                                       -- Mike

Marius

---

From: Phil Hunt <[email-masked]>
Date: Fri, 3 Mar 2017 17:22:07 -0800

This thread here suggests that with “alg”:”none” cert could be modified to make it look like it isn’t at SET and be used as an access token.

If it does not matter, we need to include the conditions where “alg”:”none” is safe to use.  E.g. the assertions are shared in a back-channel not associated with users and secured by mutual TLS so no third party could intercept.

Phil

> On Mar 3, 2017, at 4:48 PM, Mike Jones <[email-masked]> wrote:
> 
> On Mar 3, 2017, at 2:32 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Fri, Mar 3, 2017 at 11:22 AM, Vivek Biswas <[email-masked] <mailto:[email-masked]>> wrote:
> https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/ <https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/>
> On Thu, Mar 2, 2017 at 6:12 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> It’s not a legal JWT implementation if it doesn’t implement “crit”.  Perhttps://tools.ietf.org/html/rfc7515#section-4.1.11 <https://tools.ietf.org/html/rfc7515#section-4.1.11>, “This Header Parameter MUST be understood and processed by implementations”.  If you know of implementations that don’t support it, we should lobby to get them fixed, rather than trying to work around bugs in those implementations.
>  
> To: Phil Hunt <[email-masked] <mailto:[email-masked]>>
> Cc: Brian Campbell <[email-masked] <mailto:[email-masked]>>; William Denniss <[email-masked] <mailto:[email-masked]>>; Mike Jones <[email-masked] <mailto:[email-masked]>>; ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> On Thu, Mar 2, 2017 at 8:05 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> On Mar 2, 2017, at 8:03 AM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Interesting!  +1
>  
> Phil
>  
> Not that it makes a difference helping the situation here but "typ" is a JOSE header rather than a JWT claim (seehttps://tools.ietf.org/html/rfc7515#section-4.1.9 <https://tools.ietf.org/html/rfc7515#section-4.1.9> andhttps://tools.ietf.org/html/rfc7516#section-4.1.11 <https://tools.ietf.org/html/rfc7516#section-4.1.11> andhttps://tools.ietf.org/html/rfc7519#section-5.1 <https://tools.ietf.org/html/rfc7519#section-5.1>).
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 4 Mar 2017 17:56:01 -0500

3:

Put "iss" and "sub" inside the event when they apply to the event, even 
if they're the same as the "iss" and "sub" of the event token itself.

  -- Justin

On 3/1/2017 1:27 PM, Phil Hunt 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 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.
>
> 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:
>>     {
> * “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 SCIM where resources have URIs: 
>  “uri”:”https://scim.example.com/Users/44f6142df96bd6ab61e7521d9"
>
> www.independentid.com <http://www.independentid.com>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Sat, 4 Mar 2017 16:55:50 -0800

That seems unclear. 

Do you mean put subj ans issuer inside the payload regardless of whether the issuer of the event is the same or different from the subject?  That way it is always the same though it may be duplicative?

Phil

> On Mar 4, 2017, at 2:56 PM, Justin Richer <[email-masked]> wrote:
> 
> 3:
> 
> Put "iss" and "sub" inside the event when they apply to the event, even if they're the same as the "iss" and "sub" of the event token itself. 
>  -- Justin

---

From: Mike Jones <[email-masked]>
Date: Sun, 5 Mar 2017 01:18:24 +0000

Agreed that this is unclear.  Duplicating information in a protocol *always* introduces an unnecessary error case – the need to define how to handle the situation in which two pieces of information that are required to be identical are different.  Information in a SET should occur at most once.

– Mike

From: Phil Hunt (IDM)<mailto:[email-masked]>
Sent: Saturday, March 4, 2017 4:56 PM
To: Justin Richer<mailto:[email-masked]>
Cc: ID Events Mailing List<mailto:[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

That seems unclear.

Phil

On Mar 4, 2017, at 2:56 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

3:

 -- Justin

Two options:

1. Leave as is.

We currently have:

   {

     "sub": "248289761001",
     "iat": 1458496025,

Could be represented as:

   {

     “esub": {

       “sub”:"248289761001”,

     }

"iat": 1458496025, "iss": "https://my.examplemed.com<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:

Phil

---

From: Justin Richer <[email-masked]>
Date: Sun, 5 Mar 2017 08:13:12 -0500

Yes, exactly. I believe the event payload should have clearly defined 
semantics within the event object itself. Claims within the object are 
defined and controlled by the event, and things outside the object are 
applicable to the SET itself. We already have several use cases listed 
where the issuer is different for the token and the event, and the 
subject and audience may be different as well. It's clear to me that 
this indicates that we should have clearly defined separation between 
the envelope (the SET) and the payload (the event).

I believe that duplication of information *lessens* the chance of error 
cases as there's now only one way to interpret each piece of data. If I 
get a token and I read "payload.iss" I know that it's the issuer of the 
SET. If I then read "payload.heart-resource-server-access-uri.iss" I 
know it's the issuer of the HEART audit event (to throw a strawman of 
one of many examples out there).

Yes, an event type could define its payload to never include "iss" 
inside of it and say "the issuer of the SET MUST be the same as the 
issuer of the event", if you really feel like optimizing things in your 
particular use case. But I do need to ask why you'd do that to yourself: 
If both issuers (or subjects, or audiences) are the same, then what harm 
is there in repeating the information other than to make the event body 
potentially larger? These aren't ID tokens being chucked around in 
browsers, so if that's the motivation I ask if we're not pre-optimizing 
a problem that we don't have.

In all cases I believe the SET definition should be very clear that any 
claims at the root apply to the SET itself and don't automatically flow 
down to the events inside the data objects within. The claims inside the 
event objects should be strictly more specifically applied to the events 
themselves.

  -- Justin

On 3/4/2017 7:55 PM, Phil Hunt (IDM) wrote:
> That seems unclear.
>
> Do you mean put subj ans issuer inside the payload regardless of 
> whether the issuer of the event is the same or different from the 
> subject?  That way it is always the same though it may be duplicative?
>
> Phil
>
>> Put "iss" and "sub" inside the event when they apply to the event, 
>> even if they're the same as the "iss" and "sub" of the event token 
>> itself.
>>
>>  -- Justin
>>
>>> then we’re potentially causing web access management systems to 
>>> reject SETs as invalid access tokens — this is theoretically a GOOD 
>>> THING.
>>>
>>> “iss”, “sub” (which follow current defs), and probably “uri” for 
>>> those entities that are referenceable as a URI.  Examples of URI 
>>> subjects:

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 6 Mar 2017 12:56:30 +0200

I would like to have separate discussion on:
* Whether SETs must be signed or alg:none is legitimate (where I 
understand Mike's position that tightening things up might push people 
with different use cases away from SET).
* Whether SETs can be used/abused as access tokens.

I think the two questions are unrelated. Regardless if all or only some 
SETs are signed, they can still be portable into unintended situations. 
So if we can avoid such portability, e.g. by removing "sub" or forcing a 
"typ" field, we definitely should.

Thanks,
	Yaron

On 04/03/17 03:22, Phil Hunt wrote:
> This thread here suggests that with “alg”:”none” cert could be modified
> to make it look like it isn’t at SET and be used as an access token.
>
> If it does not matter, we need to include the conditions where
> “alg”:”none” is safe to use.  E.g. the assertions are shared in a
> back-channel not associated with users and secured by mutual TLS so no
> third party could intercept.
>
>
> Phil
>
>> On Mar 3, 2017, at 4:48 PM, Mike Jones <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> That’s another issue that’s already been well-discussed.  There are
>> plenty of cases in which “alg”: “none” is the right level of integrity
>> protection for JWTs – including SETs.  This is the case when, for
>> instance, the JWT or SET is already integrity protected by the
>> transport – such as TLS.  We should definitely leave the choice of
>> JWT/SET algorithms up to the application – just like the base JWT spec
>> did.
>>
>> I understand the urge to “tighten things up” but it’s often the case
>> when we “tighten things up” we’d be imposing restrictions on SETs that
>> would make them a poor match for particular use cases, causing them to
>> not use SETs at all.  The value of SETs is that they define an
>> “events” claim and its usage within JWTs.  Unless there are compelling
>> reasons to go further, we should stop there and declare victory.
>>
>>                                                                 -- Mike
>>
>> *From:* Phil Hunt (IDM) [mailto:[email-masked]]
>> *Sent:* Friday, March 3, 2017 3:34 PM
>> *To:* Brian Campbell <[email-masked]
>> <mailto:[email-masked]>>
>> *Cc:* Vivek Biswas <[email-masked]
>> <mailto:[email-masked]>>; Marius Scurtescu
>> <[email-masked] <mailto:[email-masked]>>; Mike Jones
>> <[email-masked] <mailto:[email-masked]>>;
>> William Denniss <[email-masked] <mailto:[email-masked]>>; ID
>> Events Mailing List <[email-masked] <mailto:[email-masked]>>
>> *Subject:* Re: [Id-event] Making SETs distinct as JWTs (was: Re:
>> Thread: Clarifying use of sub and iss in SET tokens)
>>
>> Would we want to make signing mandatory to ensure SET differentiation
>> is protected (in addition to the other benefits)?
>>
>> Phil
>>
>>
>> On Mar 3, 2017, at 2:32 PM, Brian Campbell <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     On Fri, Mar 3, 2017 at 11:22 AM, Vivek Biswas
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         I am not a big fan of defining type within the header field of
>>         the JWT since the header field is not signed and decisions can
>>         be influenced by doing MIM attacks.
>>
>>         See article
>>         *From:* Marius Scurtescu [mailto:[email-masked]
>>         <mailto:[email-masked]>]
>>         *Subject:* Re: [Id-event] Making SETs distinct as JWTs (was:
>>         Re: Thread: Clarifying use of sub and iss in SET tokens)
>>
>>         On Thu, Mar 2, 2017 at 6:12 PM, Mike Jones
>>         <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>
>>             It’s not a legal JWT implementation if it doesn’t
>>             implement “crit”.
>>             Perhttps://tools.ietf.org/html/rfc7515#section-4.1.11,
>>             “This Header Parameter MUST be understood and processed by
>>             implementations”.  If you know of implementations that
>>             don’t support it, we should lobby to get them fixed,
>>             rather than trying to work around bugs in those
>>             implementations.
>>
>>
>>             Again, doing general-purpose JWT work is not in the scope
>>             of this working group.  (The OAuth WG owns that.)  Doing
>>             SecEvent-specific JWT work is in scope.
>>
>>
>>         I totally understand that Mike, but to me it looked like there
>>         is no good solution in scope for this working group, so I
>>         suggested we escalate.
>>
>>
>>
>>             -- Mike
>>
>>             *From:* Marius Scurtescu [mailto:[email-masked]
>>             <mailto:[email-masked]>]
>>             *To:* Phil Hunt <[email-masked]
>>             <mailto:[email-masked]>>
>>             *Cc:* Brian Campbell <[email-masked]
>>             <mailto:[email-masked]>>; William Denniss
>>             <[email-masked] <mailto:[email-masked]>>; Mike
>>             Jones <[email-masked]
>>             <mailto:[email-masked]>>; ID Events Mailing
>>             List <[email-masked] <mailto:[email-masked]>>
>>             *Subject:* Re: [Id-event] Making SETs distinct as JWTs
>>             (was: Re: Thread: Clarifying use of sub and iss in SET tokens)
>>
>>             I did not realize that typ is a header. Shouldn't ideally
>>             the SET purpose or "type" be a claim rather?
>>
>>             I doubt that any existing libraries take crit into
>>             account. Can anyone point to a library that does look at
>>             crit? With that in mind, crit does not help much IMO, we
>>             might just as well define a type claim.
>>
>>             Marius
>>
>>             On Thu, Mar 2, 2017 at 8:05 AM, Phil Hunt
>>             <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>                     On Mar 2, 2017, at 8:03 AM, Phil Hunt
>>                     <[email-masked]
>>                     <mailto:[email-masked]>> wrote:
>>
>>                     Interesting!  +1
>>
>>                     Phil
>>
>>                         On Mar 2, 2017, at 7:53 AM, Brian Campbell
>>                         <[email-masked]
>>                         <mailto:[email-masked]>> wrote:
>>
>>
>>                         Not that it makes a difference helping the
>>                         situation here but "typ" is a JOSE header
>>                         rather than a JWT claim
>>                         (seehttps://tools.ietf.org/html/rfc7515#section-4.1.9 andhttps://tools.ietf.org/html/rfc7516#section-4.1.11 andhttps://tools.ietf.org/html/rfc7519#section-5.1).
>>
>>                         That got me thinking, however, that maybe the
>>                         "crit" JOSE header
>>                         (https://tools.ietf.org/html/rfc7515#section-4.1.11)
>>                         might be useful here. Assuming JWT/JOSE
>>                         implementations support "crit" per spec (they
>>                         *should* but that might be an optimistic
>>                         assumption) then it could be used to address
>>                         the 'clients already written that don't check
>>                         for it' problem. Something like a new "set"
>>                         header that gets marked as critical. I.e. as
>>                         just a strawman,
>>
>>                              {
>>                               "alg":"ES256",
>>
>>                               "crit":["set"],
>>
>>                               "set":true
>>
>>                              }
>>
>>                         says that the receiver must understand and
>>                         process the "set" header, which existing OIDC
>>                         and OAuth JWT consumers wouldn't.
>>
>>                         On Wed, Mar 1, 2017 at 7:05 PM, William
>>                         Denniss <[email-masked]
>>                         <mailto:[email-masked]>> wrote:
>>
>>
>>
>>                             On Wed, Mar 1, 2017 at 5:52 PM, Marius
>>                             Scurtescu <[email-masked]
>>                             <mailto:[email-masked]>> wrote:
>>
>>                                 On Wed, Mar 1, 2017 at 5:30 PM,
>>                                 William Denniss <[email-masked]
>>                                 <mailto:[email-masked]>> wrote:
>>
>>
>>                                     On Wed, Mar 1, 2017 at 5:05 PM,
>>                                     Marius Scurtescu
>>                                     <[email-masked]
>>                                     <mailto:[email-masked]>> wrote:
>>
>>                                         On Wed, Mar 1, 2017 at 4:50
>>                                         PM, William Denniss
>>                                         <[email-masked]
>>                                         <mailto:[email-masked]>>
>>                                         wrote:
>>
>>                                                 As a concrete example,
>>                                                 let's say an RP that
>>                                                 supports OIDC decides
>>                                                 to also implement
>>                                                 RISC/SET. When they
>>                                                 read the spec and
>>                                                 decide on
>>                                                 implementation they
>>                                                 realize that they also
>>                                                 have to modify the
>>                                                 existing OIDC
>>                                                 implementation so it
>>                                                 does not accept Id
>>                                                 Token looking JWTs
>>                                                 that have an "events"
>>                                                 claim. It is very easy
>>                                                 to miss this
>>                                                 requirement. But more
>>                                                 important, when the
>>                                                 next JWT application
>>                                                 is implemented they
>>                                                 might have to yet
>>                                                 again update the
>>                                                 existing OIDC
>>                                                 implementation, and so
>>                                                 forth.
>>
>>
>>                                             Why would the RISC
>>                                             implementation reuse the
>>                                             same iss/aud pair as the
>>                                             OIDC implementation?
>>
>>
>>                                         iss naturally would be the
>>                                         same in most cases. I would
>>                                         argue that aud would also
>>                                         naturally be the same, the
>>                                         client id, since that is the
>>                                         intended recipient. Having aud
>>                                         be the URL of the target
>>                                         endpoint for example (the only
>>                                         suggestion I am aware of), is
>>                                         hackish at best. The same
>>                                         endpoint could be shared by
>>                                         multiple clients in some
>>                                         cases. Also, this couples
>>                                         creating the SET with delivery
>>                                         details
>>
>>
>>                                     Why not change iss for RISC?
>>                                      https://issuer.google.com/risc for example.
>>
>>
>>                             We'd have to host the keys multiple times,
>>                             but they *could* still be the same keys,
>>                             right?
>>
>>
>>
>>                                             If it didn't, there's no
>>                                             issue!
>>
>>
>>                                         There might be no issue for
>>                                         SET, but we are going to run
>>                                         into this problem over and
>>                                         over again.
>>
>>
>>
>>                                             Isn't this the simplest
>>                                             approach? Given that "typ"
>>                                             isn't mandated by JWT, I
>>                                             think that this is
>>                                             therefore the implied
>>                                             method for segregating
>>                                             JWTs by the usage intent.
>>
>>
>>                                         Not sure what you mean by
>>                                         "this". Replacing typ with
>>                                         unique iss/aud combinations?
>>
>>
>>                                     systems will consume which have
>>                                     different concerns.  Reading
>>                                     RFC7519, I don't see any way to
>>                                     separate those concerns, other
>>                                     than with iss/aud.  RFC7519
>>                                     doesn't say "each spec that uses
>>                                     JWT should use a unique
>>                                     combination of claims such at no
>>                                     other spec could accidently
>>                                     interpret it as meant for them"
>>                                     (and I'm not convinced this is
>>                                     scalable, or desirable).  Nor does
>>                                     it require the use of a type claim
>>                                     to achieve the usage segregation,
>>                                     and it's too late to add one now.
>>
>>
>>                                 I totally agree that we have no ideal
>>                                 solution here. Having each application
>>                                 define its own URN (or some schema)
>>                                 for aud might work, even if ugly. This
>>                                 is similar to merging typ into aud. Do
>>                                 we have any concrete proposals here?
>>
>>
>>                             Defining a structured aud format could
>>                             solve this, I agree – like you say, it's
>>                             merging type into aud in a way that's
>>                             backwards compatible.  Personally I don't
>>                             mind that approach, but I recall some
>>                             resistance to it.
>>
>>                             Some kind of separation based on iss or
>>                             aud I think is going to be the safest and
>>                             most scalable solution.
>>
>>
>>                                             On Wed, Mar 1, 2017 at
>>                                             4:36 PM, Marius Scurtescu
>>                                             <[email-masked]
>>                                             <mailto:[email-masked]>>
>>                                             wrote:
>>
>>                                                 Mike, me providing a
>>                                                 bulletproof example is
>>                                                 irrelevant I think. I
>>                                                 am trying to convey a
>>                                                 general idea. My point
>>                                                 is that having to
>>                                                 continuously update
>>                                                 existing
>>                                                 implementations with
>>                                                 new validation rules
>>                                                 is error prone and
>>                                                 less likely to happen
>>                                                 that having to do one
>>                                                 generic update.
>>
>>                                                 Marius
>>
>>                                                 On Wed, Mar 1, 2017 at
>>                                                 4:31 PM, Mike Jones
>>                                                 <[email-masked]
>>                                                 <mailto:[email-masked]>>
>>                                                 wrote:
>>
>>                                                     Except that your
>>                                                     example isn’t one
>>                                                     in which there’s
>>                                                     an actual
>>                                                     problem.  For all
>>                                                     response_types
>>                                                     except for “code”,
>>                                                     the ID Token must
>>                                                     have a “nonce”
>>                                                     claim matching the
>>                                                     request in order
>>                                                     to be validated.
>>                                                     SETs won’t have
>>                                                     this claim.  For
>>                                                     response_type=code, the
>>                                                     ID Token must be
>>                                                     retrieved from the
>>                                                     Token Endpoint to
>>                                                     be valid.  But
>>                                                     SETs aren’t
>>                                                     returned as the
>>                                                     id_token value
>>                                                     from the Token
>>                                                     Endpoint.  There
>>                                                     isn’t a channel in
>>                                                     which an attacker
>>                                                     can successfully
>>                                                     substitute a SET
>>                                                     for an ID Token
>>                                                     and have it
>>                                                     validate as an ID
>>                                                     Token.
>>
>>                                                     Following the
>>                                                     advice to also
>>                                                     verify that there
>>                                                     isn’t an “events”
>>                                                     claim in an ID
>>                                                     Token provides
>>                                                     redundancy and is
>>                                                     good hygiene but
>>                                                     isn’t actually
>>                                                     even necessary to
>>                                                     prevent
>>                                                     substitution attacks.
>>
>>
>>                                                     -- Mike
>>
>>                                                     *From:* Marius
>>                                                     Scurtescu
>>                                                     [mailto:[email-masked]
>>                                                     <mailto:[email-masked]>]
>>                                                     *Sent:* Wednesday,
>>                                                     March 1, 2017 4:22 PM
>>                                                     *To:* Mike Jones
>>                                                     <[email-masked]
>>                                                     <mailto:[email-masked]>>
>>                                                     *Cc:* William
>>                                                     Denniss
>>                                                     <[email-masked]
>>                                                     <mailto:[email-masked]>>;
>>                                                     Phil Hunt (IDM)
>>                                                     <[email-masked]
>>                                                     <mailto:[email-masked]>>;
>>                                                     ID Events Mailing
>>                                                     List
>>                                                     <[email-masked]
>>                                                     <mailto:[email-masked]>>
>>
>>                                                     *Subject:* Re:
>>                                                     [Id-event] Thread:
>>                                                     Clarifying use of
>>                                                     sub and iss in SET
>>                                                     tokens
>>
>>
>>                                                     As a concrete
>>                                                     example, let's say
>>                                                     an RP that
>>                                                     supports OIDC
>>                                                     decides to also
>>                                                     implement
>>                                                     RISC/SET. When
>>                                                     they read the spec
>>                                                     and decide on
>>                                                     implementation
>>                                                     they realize that
>>                                                     they also have to
>>                                                     modify the
>>                                                     existing OIDC
>>                                                     implementation so
>>                                                     it does not accept
>>                                                     Id Token looking
>>                                                     JWTs that have an
>>                                                     "events" claim. It
>>                                                     is very easy to
>>                                                     miss this
>>                                                     requirement. But
>>                                                     more important,
>>                                                     when the next JWT
>>                                                     application is
>>                                                     implemented they
>>                                                     might have to yet
>>                                                     again update the
>>                                                     existing OIDC
>>                                                     implementation,
>>                                                     and so forth.
>>
>>                                                     One simpler fix
>>                                                     would be to modify
>>                                                     the OIDC
>>                                                     implementation
>>                                                     once to look for
>>                                                     the correct "typ"
>>                                                     claim (assuming
>>                                                     one is defined).
>>                                                     The security
>>                                                     considerations in
>>                                                     the SET spec could
>>                                                     specify that due
>>                                                     to iss/aud overlap
>>                                                     it is crucial that
>>                                                     typ is validated
>>                                                     in all related
>>                                                     implementations.
>>
>>                                                     I understand that
>>                                                     typ cannot be
>>                                                     standardized by
>>                                                     the SET spec for
>>                                                     other specs (but
>>                                                     it could
>>                                                     definitely clearly
>>                                                     define it for
>>                                                     SET), but I think
>>                                                     the sooner we do
>>                                                     that for all
>>                                                     relevant specs the
>>                                                     better.
>>
>>
>>
>>                                                     Marius
>>
>>                                                     On Wed, Mar 1,
>>                                                     2017 at 4:07 PM,
>>                                                     Mike Jones
>>                                                     <[email-masked]
>>                                                     <mailto:[email-masked]>>
>>                                                     wrote:
>>
>>                                                         Of course,
>>                                                         there is
>>                                                         already a
>>                                                         “typ” claim.
>>                                                         Its use is
>>                                                         optional,
>>                                                         since whether
>>                                                         it’s needed is
>>                                                         application-specific.
>>
>>                                                         Your
>>                                                         suggestion
>>                                                         that we issue
>>                                                         general-purpose JWT
>>                                                         guidance about
>>                                                         iss/aud
>>                                                         namespaces is
>>                                                         exactly the
>>                                                         kind of thing
>>                                                         that’s beyond
>>                                                         the scope of
>>                                                         this working
>>                                                         group, per my
>>                                                         just-sent
>>                                                         reply to
>>                                                         Marius.
>>                                                         Suggesting
>>                                                         that
>>                                                         applications
>>                                                         use the
>>                                                         “events” claim
>>                                                         to distinguish
>>                                                         between SETs
>>                                                         and other
>>                                                         kinds of JWTs
>>                                                         is within the
>>                                                         scope of this
>>                                                         working group,
>>                                                         because it is
>>                                                         advice about
>>                                                         using SETs.
>>
>>
>>                                                         -- Mike
>>
>>                                                         *From:* William Denniss
>>                                                         [mailto:[email-masked]
>>                                                         <mailto:[email-masked]>]
>>                                                         *Sent:* Wednesday,
>>                                                         March 1, 2017
>>                                                         4:00 PM
>>                                                         *To:* Marius
>>                                                         Scurtescu
>>                                                         <[email-masked]
>>                                                         <mailto:[email-masked]>>
>>                                                         *Cc:* Phil
>>                                                         Hunt (IDM)
>>                                                         <[email-masked]
>>                                                         <mailto:[email-masked]>>;
>>                                                         Mike Jones
>>                                                         <[email-masked]
>>                                                         <mailto:[email-masked]>>;
>>                                                         ID Events
>>                                                         Mailing List
>>                                                         <[email-masked]
>>                                                         <mailto:[email-masked]>>
>>                                                         *Subject:* Re:
>>                                                         [Id-event]
>>                                                         Thread:
>>                                                         Clarifying use
>>                                                         of sub and iss
>>                                                         in SET tokens
>>
>>                                                         If JWT had a
>>                                                         "typ" field
>>                                                         all along,
>>                                                         this entire
>>                                                         discussion
>>                                                         could be
>>                                                         avoided, but
>>                                                         it's too late
>>                                                         for that now.
>>                                                         I believe that
>>                                                         this was
>>                                                         actually the
>>                                                         founding
>>                                                         reason behind
>>                                                         standardizing
>>                                                         SET,
>>                                                         introducing
>>                                                         the "events"
>>                                                         claim. At
>>                                                         least, to
>>                                                         avoid the 3+
>>                                                         versions of
>>                                                         event-on-JWT
>>                                                         that were in
>>                                                         discussion at
>>                                                         the time.
>>
>>                                                         As with all
>>                                                         security
>>                                                         considerations
>>                                                         people can not
>>                                                         follow them
>>                                                         and have bad
>>                                                         things happen.
>>
>>                                                         Doesn't
>>                                                         suggesting
>>                                                         that unrelated
>>                                                         systems not
>>                                                         issue tokens
>>                                                         sharing the
>>                                                         same iss/aud
>>                                                         namespace make
>>                                                         sense here as
>>                                                         a mitigation
>>                                                         though?  To me
>>                                                         that's better
>>                                                         and more
>>                                                         scalable than
>>                                                         every spec
>>                                                         removing some
>>                                                         required claim
>>                                                         from the other
>>                                                         specs (e.g.
>>                                                         mandating that
>>                                                         people can't
>>                                                         use "sub").
>>
>>
>>                                                         On Wed, Mar 1,
>>                                                         2017 at 3:54
>>                                                         PM, Marius
>>                                                         Scurtescu
>>                                                         <[email-masked]
>>                                                         <mailto:[email-masked]>>
>>                                                         wrote:
>>
>>                                                             We also
>>                                                             talked
>>                                                             about
>>                                                             adding
>>                                                             another
>>                                                             claim that
>>                                                             defines
>>                                                             the type
>>                                                             or purpose
>>                                                             of the JWT
>>                                                             ("access
>>                                                             token",
>>                                                             "SET",
>>                                                             etc). In a
>>                                                             way it is
>>                                                             the only
>>                                                             sane
>>                                                             option,
>>                                                             but it is
>>                                                             not
>>                                                             addressing
>>                                                             existing
>>                                                             implementations.
>>                                                             Asking
>>                                                             implementors
>>                                                             to "be
>>                                                             careful"
>>                                                             is asking
>>                                                             for
>>                                                             trouble
>>                                                             IMO,
>>                                                             especially
>>                                                             because
>>                                                             systems
>>                                                             evolve by
>>                                                             incrementally
>>                                                             adding
>>                                                             functionality.
>>
>>                                                             Marius
>>
>>                                                             On Wed,
>>                                                             Mar 1,
>>                                                             2017 at
>>                                                             12:44 PM,
>>                                                             William
>>                                                             Denniss
>>                                                             <[email-masked]
>>                                                             <mailto:[email-masked]>>
>>                                                             wrote:
>>
>>                                                                 OK so
>>                                                                 perhaps the
>>                                                                 "URI"
>>                                                                 thing
>>                                                                 is
>>                                                                 overly
>>                                                                 restrictive.
>>
>>                                                                 I
>>                                                                 guess
>>                                                                 the
>>                                                                 security
>>                                                                 consideration
>>                                                                 I'm
>>                                                                 recommending
>>                                                                 here
>>                                                                 is
>>                                                                 that
>>                                                                 you
>>                                                                 shouldn't
>>                                                                 have
>>                                                                 multiple
>>                                                                 systems that
>>                                                                 issue
>>                                                                 JWTs
>>                                                                 with
>>                                                                 the
>>                                                                 same
>>                                                                 iss/aud tuple,
>>                                                                 except
>>                                                                 when
>>                                                                 those
>>                                                                 systems are
>>                                                                 tightly coupled
>>                                                                 (as is
>>                                                                 the
>>                                                                 case
>>                                                                 with
>>                                                                 Connect &
>>                                                                 Logout).
>>
>>                                                                 If a
>>                                                                 shared
>>                                                                 issuer
>>                                                                 is
>>                                                                 used,
>>                                                                 then
>>                                                                 URI-based
>>                                                                 namespacing
>>                                                                 is
>>                                                                 *one*
>>                                                                 way to
>>                                                                 avoid
>>                                                                 this,
>>                                                                 but
>>                                                                 there
>>                                                                 are
>>                                                                 others.
>>
>>                                                                 I'm
>>                                                                 trying
>>                                                                 to
>>                                                                 avoid
>>                                                                 the
>>                                                                 need
>>                                                                 for
>>                                                                 SET to
>>                                                                 "break" possible
>>                                                                 use in
>>                                                                 access
>>                                                                 tokens
>>                                                                 (one
>>                                                                 of the
>>                                                                 stated
>>                                                                 goals
>>                                                                 in the
>>                                                                 original
>>                                                                 post)
>>                                                                 – I
>>                                                                 think
>>                                                                 having
>>                                                                 advice
>>                                                                 like
>>                                                                 this
>>                                                                 can
>>                                                                 avoid
>>                                                                 normative
>>                                                                 language
>>                                                                 that
>>                                                                 changes,
>>                                                                 and
>>                                                                 overly
>>                                                                 complicates
>>                                                                 SET.
>>
>>
>>                                                                 Id-event
>>                                                                 mailing list
>>                                                                 <mailto:[email-masked]>

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Mar 2017 00:39:36 +0000

Justin, I suspect you didn’t see my earlier reply to Phil’s note that you also replied to, so I’m repeating it here and sending it to you directly.  (It wouldn’t be the first time that DMARC policies caused some of my contributions to be not received by some participants. :-( )

– Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Sunday, March 5, 2017 5:13 AM
To: Phil Hunt (IDM) <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Yes, exactly. I believe the event payload should have clearly defined semantics within the event object itself. Claims within the object are defined and controlled by the event, and things outside the object are applicable to the SET itself. We already have several use cases listed where the issuer is different for the token and the event, and the subject and audience may be different as well. It's clear to me that this indicates that we should have clearly defined separation between the envelope (the SET) and the payload (the event).

I believe that duplication of information *lessens* the chance of error cases as there's now only one way to interpret each piece of data. If I get a token and I read "payload.iss" I know that it's the issuer of the SET. If I then read "payload.heart-resource-server-access-uri.iss" I know it's the issuer of the HEART audit event (to throw a strawman of one of many examples out there).

Yes, an event type could define its payload to never include "iss" inside of it and say "the issuer of the SET MUST be the same as the issuer of the event", if you really feel like optimizing things in your particular use case. But I do need to ask why you'd do that to yourself: If both issuers (or subjects, or audiences) are the same, then what harm is there in repeating the information other than to make the event body potentially larger? These aren't ID tokens being chucked around in browsers, so if that's the motivation I ask if we're not pre-optimizing a problem that we don't have.

In all cases I believe the SET definition should be very clear that any claims at the root apply to the SET itself and don't automatically flow down to the events inside the data objects within. The claims inside the event objects should be strictly more specifically applied to the events themselves.

 -- Justin

Phil

3:

 -- Justin

Two options:

1. Leave as is.

We currently have:

   {

     "sub": "248289761001",

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com"

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Could be represented as:

   {

     “esub": {

       “sub”:"248289761001”,

     }

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com"

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Comments:

Phil

Id-event mailing list

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 6 Mar 2017 16:49:07 -0800

In my view it is only simple  if we keep iss and sub together. This creates the conflict when the SET issuer is not same as the subject issuer. For example when an RP issues an event about an IDP/OP's subject. This will happen a LOT. 

I do not believe the current text actually works in this regard. I would prefer not to punt this to profiling specs to clarify as this will create a lot of interop and inconsistent use issues. 

I think Justin has a point here. 

Phil

> On Mar 6, 2017, at 4:39 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 Mar 2017 18:55:13 -0600

On 03/06/2017 06:39 PM, Mike Jones wrote:
>
> Justin, I suspect you didn’t see my earlier reply to Phil’s note that
> you also replied to, so I’m repeating it here and sending it to you
> directly.  (It wouldn’t be the first time that DMARC policies caused
> some of my contributions to be not received by some participants. :-( )
>
>  
>
> Agreed that this is unclear.  Duplicating information in a protocol
> **always** introduces an unnecessary error case – the need to define
> how to handle the situation in which two pieces of information that
> are required to be identical are different.  Information in a SET
> should occur at most once.
>
>

That seems a dangerous road to tread, as it requires care in defining
"information" -- duplicating the same data strings at different levels
of the hierarchy of a JSON object may very well not be duplicating
information, due to the extra context provided by the hierarchy.  In my
mind, it's not a clear case that you should never send the same
name/value multiple times in different parts of an object, as sometimes
it is good to keep the semantic separation clear.

-Ben

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Mar 2017 00:58:47 +0000

I’m fine with the subject issuer and the subject being event parameters when the subject issuer and the event parameter can be different.  In the case in which they’re always the same, though, they shouldn’t be duplicated.  This will be the case for important classes of events.  (Also, remember when reasoning about “sub” that a “sub” claim may not be needed to identify the subject of some events – such as when the subject is the issuer itself.)

                                                                -- Mike

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Monday, March 6, 2017 4:49 PM
To: Mike Jones <[email-masked]>
Cc: Justin Richer <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Phil

On Mar 6, 2017, at 4:39 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Justin, I suspect you didn’t see my earlier reply to Phil’s note that you also replied to, so I’m repeating it here and sending it to you directly.  (It wouldn’t be the first time that DMARC policies caused some of my contributions to be not received by some participants. :-( )

– Mike

To: Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>

 -- Justin

Phil

3:

 -- Justin

Two options:

1. Leave as is.

We currently have:

   {

     "sub": "248289761001",

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com"

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Could be represented as:

   {

     “esub": {

       “sub”:"248289761001”,

     }

     "iat": 1458496025,

     "aud": [

       "https://rp.example.com"

     ],

     "events": {

         "consentUri":[

         ]

       }

     }

   }

Comments:

Phil

Id-event mailing list

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Mar 2017 01:02:57 +0000

I agree that if the two pieces of information in two fields are allowed to be different but happen to be the same, that both fields should be carried in the SET with identical values.  What I was talking about was the case in which two fields are required to be identical.  That's the case in which duplication is harmful.

                                                                -- Mike

From: Benjamin Kaduk [mailto:[email-masked]]
Sent: Monday, March 6, 2017 4:55 PM
To: Mike Jones <[email-masked]>; Justin Richer <[email-masked]>; Phil Hunt (IDM) <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Justin, I suspect you didn't see my earlier reply to Phil's note that you also replied to, so I'm repeating it here and sending it to you directly.  (It wouldn't be the first time that DMARC policies caused some of my contributions to be not received by some participants. :-( )

Agreed that this is unclear.  Duplicating information in a protocol *always* introduces an unnecessary error case - the need to define how to handle the situation in which two pieces of information that are required to be identical are different.  Information in a SET should occur at most once.

That seems a dangerous road to tread, as it requires care in defining "information" -- duplicating the same data strings at different levels of the hierarchy of a JSON object may very well not be duplicating information, due to the extra context provided by the hierarchy.  In my mind, it's not a clear case that you should never send the same name/value multiple times in different parts of an object, as sometimes it is good to keep the semantic separation clear.

-Ben

---

From: William Denniss <[email-masked]>
Date: Mon, 6 Mar 2017 17:06:26 -0800

I think SET should not be opinionated on this, and not try and solve
everything.

Backchannel logout already has an acceptable solution for their case, and
are not asking for a "fix".  It looks like RISC may create it's own
solution to solve this issue, and may not want SET to do anything.

Let's keep SET generic, in the same way JWT itself is, and add some text in
the Security Considerations.

I fear that introducing normative text (like using "crit") to "fix" an
issue with the way some people are using JWT in unrelated specs seems to be
scope-creep.  We can then focus our energies on the primary mission of the
event definition.

On Mon, Mar 6, 2017 at 4:49 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> In my view it is only simple  if we keep iss and sub together. This
> creates the conflict when the SET issuer is not same as the subject issuer.
> For example when an RP issues an event about an IDP/OP's subject. This will
> happen a LOT.
>
> I do not believe the current text actually works in this regard. I would
> prefer not to punt this to profiling specs to clarify as this will create a
> lot of interop and inconsistent use issues.
>
> Justin, I suspect you didn’t see my earlier reply to Phil’s note that you
> also replied to, so I’m repeating it here and sending it to you directly.
> (It wouldn’t be the first time that DMARC policies caused some of my
> contributions to be not received by some participants. :-( )
>
>
>
> Agreed that this is unclear.  Duplicating information in a protocol *
> *always** introduces an unnecessary error case – the need to define how
> to handle the situation in which two pieces of information that are
> required to be identical are different.  Information in a SET should occur
> at most once.
>
>
>
> – Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Justin Richer
> *Sent:* Sunday, March 5, 2017 5:13 AM
> *To:* Phil Hunt (IDM) <[email-masked]>
> where the issuer is different for the token and the event, and the subject
> and audience may be different as well. It's clear to me that this indicates
> that we should have clearly defined separation between the envelope (the
> SET) and the payload (the event).
>
> cases as there's now only one way to interpret each piece of data. If I get
> a token and I read "payload.iss" I know that it's the issuer of the SET. If
> I then read "payload.heart-resource-server-access-uri.iss" I know it's
> the issuer of the HEART audit event (to throw a strawman of one of many
> examples out there).
>
> Yes, an event type could define its payload to never include "iss" inside
> of it and say "the issuer of the SET MUST be the same as the issuer of the
> event", if you really feel like optimizing things in your particular use
> case. But I do need to ask why you'd do that to yourself: If both issuers
> (or subjects, or audiences) are the same, then what harm is there in
> repeating the information other than to make the event body potentially
> larger? These aren't ID tokens being chucked around in browsers, so if
> that's the motivation I ask if we're not pre-optimizing a problem that we
> don't have.
>
> Do you mean put subj ans issuer inside the payload regardless of whether
> the issuer of the event is the same or different from the subject?  That
> way it is always the same though it may be duplicative?
>
> Phil
>
>
> Put "iss" and "sub" inside the event when they apply to the event, even if
> they're the same as the "iss" and "sub" of the event token itself.
>
>  -- Justin
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 Mar 2017 19:06:47 -0600

I can get behind that statement! :)

(Now just to make it clear in which cases they actually are required to
be identical, whether that's subject to an OOB agreement between the
parties involved, etc....)

-Ben

On 03/06/2017 07:02 PM, Mike Jones wrote:
>
> I agree that if the two pieces of information in two fields are
> allowed to be different but happen to be the same, that both fields
> should be carried in the SET with identical values.  What I was
> talking about was the case in which two fields are required to be
> identical.  That’s the case in which duplication is harmful.
>
>  
>
>                                                                 -- Mike
>
>  
>
> *From:*Benjamin Kaduk [mailto:[email-masked]]
> *Sent:* Monday, March 6, 2017 4:55 PM
> *To:* Mike Jones <[email-masked]>; Justin Richer
> <[email-masked]>; Phil Hunt (IDM) <[email-masked]>
>     Justin, I suspect you didn’t see my earlier reply to Phil’s note
>     that you also replied to, so I’m repeating it here and sending it
>     to you directly.  (It wouldn’t be the first time that DMARC
>     policies caused some of my contributions to be not received by
>     some participants. :-( )
>
>      
>
>     Agreed that this is unclear.  Duplicating information in a
>     protocol **always** introduces an unnecessary error case – the
>     need to define how to handle the situation in which two pieces of
>     information that are required to be identical are different. 
>     Information in a SET should occur at most once.
>
>      
>
>
> information, due to the extra context provided by the hierarchy.  In
> my mind, it's not a clear case that you should never send the same
> name/value multiple times in different parts of an object, as
> sometimes it is good to keep the semantic separation clear.
>
> -Ben
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 7 Mar 2017 10:26:56 -0500

+1

---

From: Phil Hunt <[email-masked]>
Date: Tue, 7 Mar 2017 08:12:54 -0800

Just to refresh everyone...

As editor, my feeling is we have no *clean* or *simple* solution because we have to use “iss” to mean the issuer of the SET in order to comply with JWT and because OIDC conflates assertion issuer with subject issuer, it makes it difficult to uniquely identify a “sub” value because some events want to use “iss” for 2 purposes (to identify the event issuer vs. the subject issuer).

None of the solutions presented are actually easy to explain. So far, I’ve sided with Mike and William because they feel it is close enough and it was editorially lazy (say nothing). I am worried that this is actually complex for developers who do not know the history of how JWTs emerged.

Let’s look at the examples we already have. Notice that in the current draft, there are 3 separate ways of expressing the subject of an event….

Scenario 1, the event issuer and subject issuer are the same:

   {
      "iss": "https://server.example.com",
      "sub": "248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
   }

Scenario 2, a relying party is issuing an event, event iss and sub iss are different and thus there are repeat iss values:

   {

     "sub": "248289761001",
     "iat": 1458496025,

Scenario  3:  sub is universally unique:

   {
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "iat": 1458496025,
     "iss": "https://scim.example.com",
     "aud": [
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],
     "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
     "events": {
       "urn:ietf:params:scim:event:passwordReset":
         { "id":"44f6142df96bd6ab61e7521d9"},
       "https://example.com/scim/event/passwordResetExt":
         { "resetAttempts":5}
     }
   }

I believe the current argument is that profiling specs explains how their events are to be parsed. This means for multi-event parsers, subject is inconsistent and potentially not mappable.  The BackChannel Logout event is currently structured for only the OP to issue. However Oracle wants that to be bi-directional so that web sites can notify the IDP/OP that the user has logged out of a specific web site.  If that happens, BackChannel logout will have methods 1 and 2 required.

Would it be possible for events to require that “sub” be globally unique — e.g. expressed as a url.  For example, in order for backchannel to be issued by an OP or an RP, it would be expressed with sub as a URL ("sub": “https://server.example.com/248289761001”,):
   {
      "iss": "https://www.exampleapp.com",
      "sub": “https://server.example.com/248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
 
At least this way iss is never duplicated and sub is always the addressable subject of the event regardless of the type of event.  That would enable all 3 cases to be expressed one way for all specs.  That seems simple to me (at least from how I would define this in the spec).  

I had thought Justin was advocating a 4th option which is to always embed “sub” and “iss” in the event payload.  So you would end up with something like:
   {
     "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
     "iat": 1458496025,
     "iss": "https://my.examplemed.com",
     "aud": [
       "https://rp.example.com"
     ],
     "events": {
       "https://openid.net/heart/specs/consent.html":{
         "sub": "248289761001",
         "iss":"https://my.examplemed.com",
         "consentUri":[
           "https://terms.examplemed.com/labdisclosure.html#Agree"
         ]
       }
     }
   }

Note that in the above example, “iss” would always be present even if “iss” is the *same*.  The rule would be that the iss and sub are in the payload and that addresses the subject of the event. The envelope level is always reserved for event validation and addressing only.  While some would argue this is ugly, I can see some merits as it is at least consistent.

Phil

> On Mar 7, 2017, at 7:26 AM, Justin Richer <[email-masked]> wrote:
> 
> +1
> 
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Mar 2017 17:29:42 +0000

No, it's not possible to require that "sub" be globally unique because for important use cases, it's relative to the issuer.  Trying to force it to be a URI would unnecessarily limit the applicability of the SET spec, causing some applications to simply decide to not use it as a result.

If some use cases want a kind of logout event that's issued by a different party than the IdP, then the current spec lets that new event be defined.  It will require more parameters than the current logout event, but that's OK, since it's used in different contexts.

In my view, it's not editorially lazy to allow events to define what claims they need.  It's an intentional choice, which enables the simple cases to be simply expressed, while also enabling more complicated cases carrying more information to be expressed.

Trying to force the simple events use extra syntax only actually needed for complicated events would be a severe architectural mistake on our part.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Tuesday, March 7, 2017 8:13 AM
To: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

As editor, my feeling is we have no *clean* or *simple* solution because we have to use "iss" to mean the issuer of the SET in order to comply with JWT and because OIDC conflates assertion issuer with subject issuer, it makes it difficult to uniquely identify a "sub" value because some events want to use "iss" for 2 purposes (to identify the event issuer vs. the subject issuer).

None of the solutions presented are actually easy to explain. So far, I've sided with Mike and William because they feel it is close enough and it was editorially lazy (say nothing). I am worried that this is actually complex for developers who do not know the history of how JWTs emerged.

Let's look at the examples we already have. Notice that in the current draft, there are 3 separate ways of expressing the subject of an event....

   {

   {

     "sub": "248289761001",
     "iat": 1458496025,

   {

Would it be possible for events to require that "sub" be globally unique - e.g. expressed as a url.  For example, in order for backchannel to be issued by an OP or an RP, it would be expressed with sub as a URL ("sub": "https://server.example.com/248289761001",):
   {
      "iss": "https://www.exampleapp.com",
      "sub": "https://server.example.com/248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }

I had thought Justin was advocating a 4th option which is to always embed "sub" and "iss" in the event payload.  So you would end up with something like:
   {

Note that in the above example, "iss" would always be present even if "iss" is the *same*.  The rule would be that the iss and sub are in the payload and that addresses the subject of the event. The envelope level is always reserved for event validation and addressing only.  While some would argue this is ugly, I can see some merits as it is at least consistent.

Phil

On Mar 7, 2017, at 7:26 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

+1

-Ben

---

From: Phil Hunt <[email-masked]>
Date: Tue, 7 Mar 2017 10:20:52 -0800

Thanks Mike,

Just to be clear. You are expressing a perspective of maintaining the exact format as defined by the ID Token and imposing the limit on all other Events.  

If I understand correctly, JWT (RFC7519) has no such limitation on sub and the group *could* choose to profile “sub” to be globally unique for all SET Events. Correct?

What I was trying to do was point out the 3 separate subject identification formats already in the spec and to ask, is this really acceptable (per Yaron’s request)?

You and William have indicated a preference to leave it. 

Justin and Benjamin did apparently express some concerns. Can they clarify?

My concern is that we are too compatible with existing code. SETs can easily be confused as ID Tokens as existing ID Token parsers will ignore the events attribute and will see all the normal claims for an ID Token as being present.  If you can address this, then I can live with the status quo.

Are they any that have issues with the current draft (in order to get back to Yaron’s question)? The current draft allows multiple iss values to appear in different places in the JSON structure based on profiling specification definition.

Phil

> On Mar 7, 2017, at 9:29 AM, Mike Jones <[email-masked]> wrote:
> 
> No, it’s not possible to require that “sub” be globally unique because for important use cases, it’s relative to the issuer.  Trying to force it to be a URI would unnecessarily limit the applicability of the SET spec, causing some applications to simply decide to not use it as a result.
>  
> If some use cases want a kind of logout event that’s issued by a different party than the IdP, then the current spec lets that new event be defined.  It will require more parameters than the current logout event, but that’s OK, since it’s used in different contexts.
>  
> In my view, it’s not editorially lazy to allow events to define what claims they need.  It’s an intentional choice, which enables the simple cases to be simply expressed, while also enabling more complicated cases carrying more information to be expressed.
>  
>       "iss": "https://server.example.com <https://server.example.com/>",
>       "sub": "248289761001",
>       "aud": "s6BhdRkqt3",
>       "iat": 1471566154,
>       "jti": "bWJq",
>         "http://schemas.openid.net/event/backchannel-logout <http://schemas.openid.net/event/backchannel-logout>": {}
>       }
>    }
>  
>      "iss": "https://scim.example.com <https://scim.example.com/>",
>      "aud": [
>        "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754 <https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754>",
>        "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7 <https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7>"
>      ],
>      "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9 <https://scim.example.com/Users/44f6142df96bd6ab61e7521d9>",
>      "events": {
>        "https://example.com/scim/event/passwordResetExt <https://example.com/scim/event/passwordResetExt>":
>          { "resetAttempts":5}
>      }
>    }
>  
> Would it be possible for events to require that “sub” be globally unique — e.g. expressed as a url.  For example, in order for backchannel to be issued by an OP or an RP, it would be expressed with sub as a URL ("sub": “https://server.example.com/248289761001 <https://server.example.com/248289761001>”,):
>    {
>       "iss": "https://www.exampleapp.com <https://www.exampleapp.com/>",
>       "sub": “https://server.example.com/248289761001 <https://server.example.com/248289761001>",
>       "aud": "s6BhdRkqt3",
>       "iat": 1471566154,
>       "jti": "bWJq",
>         "http://schemas.openid.net/event/backchannel-logout <http://schemas.openid.net/event/backchannel-logout>": {}
>       }
>  
>          "iss":"https://my.examplemed.com <https://my.examplemed.com/>",
>          "consentUri":[
> On Mar 7, 2017, at 7:26 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>  
> +1
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Mar 2017 18:35:04 +0000

Per my earlier reply to Marius, a SET cannot be confused with an ID Token, even if the “events” claim is ignored.  The reply explained:
“For all response_types except for “code”, the ID Token must have a “nonce” claim matching the request in order to be validated.  SETs won’t have this claim.  For response_type=code, the ID Token must be retrieved from the Token Endpoint to be valid.  But SETs aren’t returned as the id_token value from the Token Endpoint.  There isn’t a channel in which an attacker can successfully substitute a SET for an ID Token and have it validate as an ID Token.”
I hope people will stop crying wolf, saying that SETs will be confused with ID Tokens, because starting with a false premise isn’t a good way to further meaningful discussion.

*IF* used in a context in which there might be confusion, which could be true for some private access token formats, the SET can always include “crit”: [“events”].  I’m fine with the security considerations section saying that, provided that doing so is optional in the SET spec.  It’s fine for particular SETs to require it, when it’s actually needed.  That’s why “crit” is there.

The fact that there are three valid examples of differing levels of complexity in the spec is a sign of the strength of the current approach – not a sign of a flaw.  Each example includes the information that it needs and is simple as possible, given the constraints of use case.  That’s as it should be.

                                                       -- Mike

Sent: Tuesday, March 7, 2017 10:21 AM

Thanks Mike,

Phil

On Mar 7, 2017, at 9:29 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Tuesday, March 7, 2017 8:13 AM
To: ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

   {
      "iss": "https://server.example.com<https://server.example.com/>",
      "sub": "248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
   }

   {

     "sub": "248289761001",
     "iat": 1458496025,

   {
     "iss": "https://scim.example.com<https://scim.example.com/>",

      "iss": "https://www.exampleapp.com<https://www.exampleapp.com/>",

         "iss":"https://my.examplemed.com<https://my.examplemed.com/>",

Phil

+1

-Ben

---

From: Phil Hunt <[email-masked]>
Date: Tue, 7 Mar 2017 10:48:44 -0800

Should SET Token have text forbidding use of nonce?  I can’t see why nonce would ever be needed and we can call that out as the method of differentiation in the security considerations.

Phil

> On Mar 7, 2017, at 10:35 AM, Mike Jones <[email-masked]> wrote:
> 
> On Mar 7, 2017, at 9:29 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Phil Hunt
> To: ID Events Mailing List <[email-masked] <mailto:[email-masked]>>

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 7 Mar 2017 13:42:24 -0800

On Tue, Mar 7, 2017 at 10:48 AM, Phil Hunt <[email-masked]> wrote:

> Should SET Token have text forbidding use of nonce?  I can’t see why nonce
> would ever be needed and we can call that out as the method of
> differentiation in the security considerations.
>

Another method of differentiation suggested by William was the value of the
aud claim.

For Id Tokens it is the client id, for SET we could specify that the value
has a specific URN prefix followed by the client id of the receiving party.

> Per my earlier reply to Marius, a SET cannot be confused with an ID Token,
> even if the “events” claim is ignored.  The reply explained:
> “For all response_types except for “code”, the ID Token must have a
> “nonce” claim matching the request in order to be validated.  SETs won’t
> validate as an ID Token.”
> I hope people will stop crying wolf, saying that SETs will be confused
> with ID Tokens, because starting with a false premise isn’t a good way to
> further meaningful discussion.
>
> **IF** used in a context in which there might be confusion, which could
> be true for some private access token formats, the SET can always include
> “crit”: [“events”].  I’m fine with the security considerations section
> saying that, provided that doing so is optional in the SET spec.  It’s fine
> for particular SETs to require it, when it’s actually needed.  That’s why
> “crit” is there.
>
> The fact that there are three valid examples of differing levels of
> complexity in the spec is a sign of the strength of the current approach –
> not a sign of a flaw.  Each example includes the information that it needs
> and is simple as possible, given the constraints of use case.  That’s as it
> should be.
>
>                                                        -- Mike
>
> *From:* Phil Hunt [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, March 7, 2017 10:21 AM
> Just to be clear. You are expressing a perspective of maintaining the
> exact format as defined by the ID Token and imposing the limit on all other
> Events.
>
> If I understand correctly, JWT (RFC7519) has no such limitation on sub and
> the group *could* choose to profile “sub” to be globally unique for all SET
> Events. Correct?
>
> What I was trying to do was point out the 3 separate subject
> identification formats already in the spec and to ask, is this really
> acceptable (per Yaron’s request)?
>
> My concern is that we are too compatible with existing code. SETs can
> easily be confused as ID Tokens as existing ID Token parsers will ignore
> the events attribute and will see all the normal claims for an ID Token as
> being present.  If you can address this, then I can live with the status
> quo.
>
> Are they any that have issues with the current draft (in order to get back
> to Yaron’s question)? The current draft allows multiple iss values to
> appear in different places in the JSON structure based on profiling
> specification definition.
>
> Phil
>
> No, it’s not possible to require that “sub” be globally unique because for
> important use cases, it’s relative to the issuer.  Trying to force it to be
> a URI would unnecessarily limit the applicability of the SET spec, causing
> some applications to simply decide to not use it as a result.
>
> If some use cases want a kind of logout event that’s issued by a different
> party than the IdP, then the current spec lets that new event be defined.
> It will require more parameters than the current logout event, but that’s
> OK, since it’s used in different contexts.
>
> In my view, it’s not editorially lazy to allow events to define what
> claims they need.  It’s an intentional choice, which enables the simple
> cases to be simply expressed, while also enabling more complicated cases
> carrying more information to be expressed.
>
> Trying to force the simple events use extra syntax only actually needed
> for complicated events would be a severe architectural mistake on our part.
>
>                                                        -- Mike
>
> <[email-masked]>] *On Behalf Of *Phil Hunt
> *Sent:* Tuesday, March 7, 2017 8:13 AM
> *To:* ID Events Mailing List <[email-masked]>
> As editor, my feeling is we have no *clean* or *simple* solution because
> we have to use “iss” to mean the issuer of the SET in order to comply with
> JWT and because OIDC conflates assertion issuer with subject issuer, it
> makes it difficult to uniquely identify a “sub” value because some events
> want to use “iss” for 2 purposes (to identify the event issuer vs. the
> subject issuer).
>
> None of the solutions presented are actually easy to explain. So far, I’ve
> sided with Mike and William because they feel it is close enough and it was
> editorially lazy (say nothing). I am worried that this is actually complex
> for developers who do not know the history of how JWTs emerged.
>
> Let’s look at the examples we already have. Notice that in the current
> draft, there are 3 separate ways of expressing the subject of an event….
>
> Scenario 2, a relying party is issuing an event, event iss and sub iss are
> different and thus there are repeat iss values:
>
>    {
> I believe the current argument is that profiling specs explains how their
> events are to be parsed. This means for multi-event parsers, subject is
> inconsistent and potentially not mappable.  The BackChannel Logout event is
> currently structured for only the OP to issue. However Oracle wants that to
> be bi-directional so that web sites can notify the IDP/OP that the user has
> logged out of a specific web site.  If that happens, BackChannel logout
> will have methods 1 and 2 required.
>
> Would it be possible for events to require that “sub” be globally unique —
> e.g. expressed as a url.  For example, in order for backchannel to be
> issued by an OP or an RP, it would be expressed with sub as a URL ("sub": “
> https://server.example.com/248289761001”,):
>    {
> At least this way iss is never duplicated and sub is always the
> addressable subject of the event regardless of the type of event.  That
> would enable all 3 cases to be expressed one way for all specs.  That seems
> simple to me (at least from how I would define this in the spec).
>
> I had thought Justin was advocating a 4th option which is to always embed
> “sub” and “iss” in the event payload.  So you would end up with something
> like:
>    {
>     * "iss": "https://my.examplemed.com <https://my.examplemed.com/>",*
>      "aud": [
>        "https://rp.example.com"
>      ],
>      "events": {
>         * "sub": "248289761001",*
> *         "iss":"https://my.examplemed.com <https://my.examplemed.com/>",*
>          "consentUri":[
> Note that in the above example, “iss” would always be present even if
> “iss” is the *same*.  The rule would be that the iss and sub are in the
> payload and that addresses the subject of the event. The envelope level is
> always reserved for event validation and addressing only.  While some would
> argue this is ugly, I can see some merits as it is at least consistent.
>
>
> Phil
>
> "information" -- duplicating the same data strings at different levels of
> the hierarchy of a JSON object may very well not be duplicating
> mind, it's not a clear case that you should never send the same name/value
> multiple times in different parts of an object, as sometimes it is good to
> keep the semantic separation clear.
>
> -Ben
>
>
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 7 Mar 2017 13:47:37 -0800

Interesting. Though not sure we can apply it in the general spec. Let me think on it. :)

Phil

> On Mar 7, 2017, at 1:42 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> Another method of differentiation suggested by William was the value of the aud claim.
> 
> For Id Tokens it is the client id, for SET we could specify that the value has a specific URN prefix followed by the client id of the receiving party.
> 
>  
>> 
>> Phil
>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 8 Mar 2017 17:47:23 -0600

Sorry for the delay.

On 03/07/2017 12:20 PM, Phil Hunt wrote:
> exact format as defined by the ID Token and imposing the limit on all
> other Events.  
>
> If I understand correctly, JWT (RFC7519) has no such limitation on sub
> and the group *could* choose to profile “sub” to be globally unique
> for all SET Events. Correct?
>

My preference would be your "4th option" to always have "sub" and "iss"
in the events payload, even if "iss" is the same in the outer envelope
and the events payload -- it's unambiguous and easy to interpret.  Mike
has mostly convinced me that there exist environments when the two "iss"
are absolutely required to be identical and are strictly duplicated
(which lends itself naturally to the status quo).  But since I don't
understand these cases very well, I'm concerned about how to identify
those environments and whether there would be interop issues if such an
environment contained an actor that also had to interact with a more
generic environment.

> easily be confused as ID Tokens as existing ID Token parsers will
> ignore the events attribute and will see all the normal claims for an
> ID Token as being present.  If you can address this, then I can live
> with the status quo.
>

I don't think I have anything to offer to help on the disambiguation of
ID tokens and SETs issue.

-Ben

> Are they any that have issues with the current draft (in order to get
> back to Yaron’s question)? The current draft allows multiple iss
> values to appear in different places in the JSON structure based on
> profiling specification definition.
>
> Phil
>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=Ijhk2wjlr4V4-fswCLBGE38fdK1gwFfUY66tfJf7a24&e=>
>> On Mar 7, 2017, at 9:29 AM, Mike Jones <[email-masked]
>> No, it’s not possible to require that “sub” be globally unique
>> because for important use cases, it’s relative to the issuer.  Trying
>> to force it to be a URI would unnecessarily limit the applicability
>> of the SET spec, causing some applications to simply decide to not
>> use it as a result.
>>  
>> If some use cases want a kind of logout event that’s issued by a
>> different party than the IdP, then the current spec lets that new
>> event be defined.  It will require more parameters than the current
>> logout event, but that’s OK, since it’s used in different contexts.
>>  
>> claims they need.  It’s an intentional choice, which enables the
>> simple cases to be simply expressed, while also enabling more
>> complicated cases carrying more information to be expressed.
>>  
>> Trying to force the simple events use extra syntax only actually
>> needed for complicated events would be a severe architectural mistake
>> on our part.
>>  
>>                                                        -- Mike
>>  
>> *From:* Id-event [mailto:[email-masked]] *On Behalf
>> Of *Phil Hunt
>> *To:* ID Events Mailing List <[email-masked]
>> As editor, my feeling is we have no *clean* or *simple* solution
>> because we have to use “iss” to mean the issuer of the SET in order
>> to comply with JWT and because OIDC conflates assertion issuer with
>> subject issuer, it makes it difficult to uniquely identify a “sub”
>> value because some events want to use “iss” for 2 purposes (to
>> identify the event issuer vs. the subject issuer).
>>  
>> None of the solutions presented are actually easy to explain. So far,
>> I’ve sided with Mike and William because they feel it is close enough
>> and it was editorially lazy (say nothing). I am worried that this is
>> actually complex for developers who do not know the history of how
>> JWTs emerged.
>>  
>> Let’s look at the examples we already have. Notice that in the
>> current draft, there are 3 separate ways of expressing the subject of
>> an event….
>>  
>>       "iss": "https://server.example.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=aZmCu-T30ddM7EO5MTTcZLtFvxVBsTqvt157yHUeOIU&e=>",
>>       "sub": "248289761001",
>>       "aud": "s6BhdRkqt3",
>>       "iat": 1471566154,
>>       "jti": "bWJq",
>>         "http://schemas.openid.net/event/backchannel-logout
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=qmlNwMQZyc4wKMGYlcbHv4N_qYgxNWYhJxV9x_obkMQ&e=>":
>> {}
>>       }
>>    }
>>  
>> Scenario 2, a relying party is issuing an event, event iss and sub
>> iss are different and thus there are repeat iss values:
>>  
>>    {
>>      "iss": "https://my.examplemed.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__my.examplemed.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=ZkLctIH2dAoi4hhkPymZDQingbkQfHt9YgekAMKelaQ&e=>",
>>      "aud": [
>>        "https://rp.example.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__rp.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=gpNhu-LU43cxIyrYhVcrMto66IZz2Jxwa5lzPpxVTD0&e=>"
>>      ],
>>      "events": {
>>        "https://openid.net/heart/specs/consent.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_specs_consent.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=0Z-ohlyQps3JNPgGR0j_zY-sRZI274Y9zMivRDXjmis&e=>":{
>>          "iss":"https://connect.example.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__connect.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=KpM1_m5EiidPDJVV4EzmfBTYG6hneVcT8hymd-6p1BI&e=>",
>>          "consentUri":[
>>            "https://terms.examplemed.com/labdisclosure.html#Agree
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__terms.examplemed.com_labdisclosure.html-23Agree&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=AAdiJeFhv-D7NndiSyTUpmxuwaxrG64CU2JvbKF1lc0&e=>"
>>          ]
>>        }
>>      }
>>    }
>>  
>>      "iss": "https://scim.example.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__scim.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=LyBq6tEQAe7jo3Yewc_F77-CHuOYZwsa4UYyVPDCFpc&e=>",
>>      "aud": [
>>        "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jhub.example.com_Feeds_98d52461fa5bbc879593b7754&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=mOuO83TTWdG12H5jGxLpWICeVgNxA5q5xMAegwYiPeg&e=>",
>>        "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__jhub.example.com_Feeds_5d7604516b1d08641d7676ee7&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=SgkQ6fsaS-Le8I4wi1GGygVQsEZLxoN8sZQS3NvgZis&e=>"
>>      ],
>>      "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__scim.example.com_Users_44f6142df96bd6ab61e7521d9&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=FiGG_pwSjXMTe-zrlpNBMrFityNSwQdBVfjvDFMV1QE&e=>",
>>      "events": {
>>        "https://example.com/scim/event/passwordResetExt
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__example.com_scim_event_passwordResetExt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=l9vO69P8yOSS_2Gd_1ya8bJyBLwhFj_fl3yZG9ovzXo&e=>":
>>          { "resetAttempts":5}
>>      }
>>    }
>>  
>> I believe the current argument is that profiling specs explains how
>> their events are to be parsed. This means for multi-event parsers,
>> subject is inconsistent and potentially not mappable.  The
>> BackChannel Logout event is currently structured for only the OP to
>> issue. However Oracle wants that to be bi-directional so that web
>> sites can notify the IDP/OP that the user has logged out of a
>> specific web site.  If that happens, BackChannel logout will have
>> methods 1 and 2 required.
>>  
>> Would it be possible for events to require that “sub” be globally
>> unique — e.g. expressed as a url.  For example, in order for
>> backchannel to be issued by an OP or an RP, it would be expressed
>> with sub as a URL ("sub": “https://server.example.com/248289761001
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_248289761001&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=5Rnz1dzOEoK27YDktq_HMGneutBpDod8-iAqU1CgizQ&e=>”,):
>>    {
>>       "iss": "https://www.exampleapp.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.exampleapp.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=KuoD7Qelh1vowEZDz-WSjpIwC7vlR410B8RPsdfQg20&e=>",
>>       "sub": “https://server.example.com/248289761001
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_248289761001&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=5Rnz1dzOEoK27YDktq_HMGneutBpDod8-iAqU1CgizQ&e=>",
>>       "aud": "s6BhdRkqt3",
>>       "iat": 1471566154,
>>       "jti": "bWJq",
>>         "http://schemas.openid.net/event/backchannel-logout
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=qmlNwMQZyc4wKMGYlcbHv4N_qYgxNWYhJxV9x_obkMQ&e=>":
>> {}
>>       }
>>  
>> addressable subject of the event regardless of the type of event.
>>  That would enable all 3 cases to be expressed one way for all specs.
>>  That seems simple to me (at least from how I would define this in
>> the spec).  
>>  
>> I had thought Justin was advocating a 4th option which is to always
>> embed “sub” and “iss” in the event payload.  So you would end up with
>> something like:
>>    {
>>     _ "iss": "https://my.examplemed.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__my.examplemed.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=ZkLctIH2dAoi4hhkPymZDQingbkQfHt9YgekAMKelaQ&e=>",_
>>      "aud": [
>>        "https://rp.example.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__rp.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=gpNhu-LU43cxIyrYhVcrMto66IZz2Jxwa5lzPpxVTD0&e=>"
>>      ],
>>      "events": {
>>        "https://openid.net/heart/specs/consent.html
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_specs_consent.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=0Z-ohlyQps3JNPgGR0j_zY-sRZI274Y9zMivRDXjmis&e=>":{
>>         _ "sub": "248289761001",_
>> _         "iss":"https://my.examplemed.com
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__my.examplemed.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=ZkLctIH2dAoi4hhkPymZDQingbkQfHt9YgekAMKelaQ&e=>",_
>>          "consentUri":[
>>            "https://terms.examplemed.com/labdisclosure.html#Agree
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__terms.examplemed.com_labdisclosure.html-23Agree&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=AAdiJeFhv-D7NndiSyTUpmxuwaxrG64CU2JvbKF1lc0&e=>"
>>          ]
>>        }
>>      }
>>    }
>>  
>> “iss” is the *same*.  The rule would be that the iss and sub are in
>> the payload and that addresses the subject of the event. The envelope
>> level is always reserved for event validation and addressing only.
>>  While some would argue this is ugly, I can see some merits as it is
>> at least consistent.
>>  
>>  
>> Phil
>>  
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=B_jjXc15tMFqi9Ef2x7fWuBKYckJ2pchgc61F80QAWA&e=>
>>             Justin, I suspect you didn’t see my earlier reply to
>>             Phil’s note that you also replied to, so I’m repeating it
>>             here and sending it to you directly.  (It wouldn’t be the
>>             first time that DMARC policies caused some of my
>>             Agreed that this is unclear.  Duplicating information in
>>             a protocol **always** introduces an unnecessary error
>>             case – the need to define how to handle the situation in
>>             which two pieces of information that are required to be
>>             identical are different.  Information in a SET should
>>             occur at most once.
>>              
>>
>>
>>         That seems a dangerous road to tread, as it requires care in
>>         defining "information" -- duplicating the same data strings
>>         at different levels of the hierarchy of a JSON object may
>>         very well not be duplicating information, due to the extra
>>         context provided by the hierarchy.  In my mind, it's not a
>>         clear case that you should never send the same name/value
>>         multiple times in different parts of an object, as sometimes
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=GvCU0sssYF2cnSpnUau9N2MD6u_C3mtzrBtqNOwmKi0&e=>
>
>
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 9 Mar 2017 18:49:35 +0000

One use case for which there is only a single issuer and a single subject is common and straightforward.  One example is when an Identity Provider is authoritative for a digital identity that it is the issuer for.  That IdP can issue events about that digital identity.  I'll note that OpenID Connect uses are of this kind, and that the "sub" value is relative to the issuer - not globally unique.  Trying to make "sub" globally unique would be a breaking change.

                                                       -- Mike

Sent: Wednesday, March 8, 2017 3:47 PM

Sorry for the delay.

If I understand correctly, JWT (RFC7519) has no such limitation on sub and the group *could* choose to profile "sub" to be globally unique for all SET Events. Correct?

What I was trying to do was point out the 3 separate subject identification formats already in the spec and to ask, is this really acceptable (per Yaron's request)?

My preference would be your "4th option" to always have "sub" and "iss" in the events payload, even if "iss" is the same in the outer envelope and the events payload -- it's unambiguous and easy to interpret.  Mike has mostly convinced me that there exist environments when the two "iss" are absolutely required to be identical and are strictly duplicated (which lends itself naturally to the status quo).  But since I don't understand these cases very well, I'm concerned about how to identify those environments and whether there would be interop issues if such an environment contained an actor that also had to interact with a more generic environment.

I don't think I have anything to offer to help on the disambiguation of ID tokens and SETs issue.

-Ben

Are they any that have issues with the current draft (in order to get back to Yaron's question)? The current draft allows multiple iss values to appear in different places in the JSON structure based on profiling specification definition.

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=Ijhk2wjlr4V4-fswCLBGE38fdK1gwFfUY66tfJf7a24&e=>
[email-masked]<mailto:[email-masked]>

                                                       -- Mike

   {
      "iss": "https://server.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=aZmCu-T30ddM7EO5MTTcZLtFvxVBsTqvt157yHUeOIU&e=>",
      "sub": "248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=qmlNwMQZyc4wKMGYlcbHv4N_qYgxNWYhJxV9x_obkMQ&e=>": {}
      }
   }

   {

     "sub": "248289761001",
     "iat": 1458496025,
     "iss": "https://my.examplemed.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.examplemed.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=ZkLctIH2dAoi4hhkPymZDQingbkQfHt9YgekAMKelaQ&e=>",
     "aud": [
       "https://rp.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__rp.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=gpNhu-LU43cxIyrYhVcrMto66IZz2Jxwa5lzPpxVTD0&e=>"
     ],
     "events": {
       "https://openid.net/heart/specs/consent.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_specs_consent.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=0Z-ohlyQps3JNPgGR0j_zY-sRZI274Y9zMivRDXjmis&e=>":{
         "iss":"https://connect.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__connect.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=KpM1_m5EiidPDJVV4EzmfBTYG6hneVcT8hymd-6p1BI&e=>",
         "consentUri":[
           "https://terms.examplemed.com/labdisclosure.html#Agree<https://urldefense.proofpoint.com/v2/url?u=https-3A__terms.examplemed.com_labdisclosure.html-23Agree&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=AAdiJeFhv-D7NndiSyTUpmxuwaxrG64CU2JvbKF1lc0&e=>"
         ]
       }
     }
   }

   {
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "iat": 1458496025,
     "iss": "https://scim.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__scim.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=LyBq6tEQAe7jo3Yewc_F77-CHuOYZwsa4UYyVPDCFpc&e=>",
     "aud": [
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754<https://urldefense.proofpoint.com/v2/url?u=https-3A__jhub.example.com_Feeds_98d52461fa5bbc879593b7754&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=mOuO83TTWdG12H5jGxLpWICeVgNxA5q5xMAegwYiPeg&e=>",
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7<https://urldefense.proofpoint.com/v2/url?u=https-3A__jhub.example.com_Feeds_5d7604516b1d08641d7676ee7&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=SgkQ6fsaS-Le8I4wi1GGygVQsEZLxoN8sZQS3NvgZis&e=>"
     ],
     "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9<https://urldefense.proofpoint.com/v2/url?u=https-3A__scim.example.com_Users_44f6142df96bd6ab61e7521d9&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=FiGG_pwSjXMTe-zrlpNBMrFityNSwQdBVfjvDFMV1QE&e=>",
     "events": {
       "urn:ietf:params:scim:event:passwordReset":
         { "id":"44f6142df96bd6ab61e7521d9"},
       "https://example.com/scim/event/passwordResetExt<https://urldefense.proofpoint.com/v2/url?u=https-3A__example.com_scim_event_passwordResetExt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=l9vO69P8yOSS_2Gd_1ya8bJyBLwhFj_fl3yZG9ovzXo&e=>":
         { "resetAttempts":5}
     }
   }

Would it be possible for events to require that "sub" be globally unique - e.g. expressed as a url.  For example, in order for backchannel to be issued by an OP or an RP, it would be expressed with sub as a URL ("sub": "https://server.example.com/248289761001<https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_248289761001&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=5Rnz1dzOEoK27YDktq_HMGneutBpDod8-iAqU1CgizQ&e=>",):
   {
      "iss": "https://www.exampleapp.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.exampleapp.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=KuoD7Qelh1vowEZDz-WSjpIwC7vlR410B8RPsdfQg20&e=>",
      "sub": "https://server.example.com/248289761001<https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_248289761001&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=5Rnz1dzOEoK27YDktq_HMGneutBpDod8-iAqU1CgizQ&e=>",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=qmlNwMQZyc4wKMGYlcbHv4N_qYgxNWYhJxV9x_obkMQ&e=>": {}
      }

I had thought Justin was advocating a 4th option which is to always embed "sub" and "iss" in the event payload.  So you would end up with something like:
   {
     "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
     "iat": 1458496025,
     "iss": "https://my.examplemed.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.examplemed.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=ZkLctIH2dAoi4hhkPymZDQingbkQfHt9YgekAMKelaQ&e=>",
     "aud": [
       "https://rp.example.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__rp.example.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=gpNhu-LU43cxIyrYhVcrMto66IZz2Jxwa5lzPpxVTD0&e=>"
     ],
     "events": {
       "https://openid.net/heart/specs/consent.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_heart_specs_consent.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=0Z-ohlyQps3JNPgGR0j_zY-sRZI274Y9zMivRDXjmis&e=>":{
         "sub": "248289761001",
         "iss":"https://my.examplemed.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__my.examplemed.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=ZkLctIH2dAoi4hhkPymZDQingbkQfHt9YgekAMKelaQ&e=>",
         "consentUri":[
           "https://terms.examplemed.com/labdisclosure.html#Agree<https://urldefense.proofpoint.com/v2/url?u=https-3A__terms.examplemed.com_labdisclosure.html-23Agree&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=AAdiJeFhv-D7NndiSyTUpmxuwaxrG64CU2JvbKF1lc0&e=>"
         ]
       }
     }
   }

Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=B_jjXc15tMFqi9Ef2x7fWuBKYckJ2pchgc61F80QAWA&e=>
[email-masked]<mailto:[email-masked]>

+1

-Ben

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=GvCU0sssYF2cnSpnUau9N2MD6u_C3mtzrBtqNOwmKi0&e=>

Id-event mailing list

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 9 Mar 2017 11:09:31 -0800

So yes it half works for OIDC providers but it doesn't work for OIDC RPs. 

The status quo I think you are arguing for results in 4 different sets of parsing formats for subjects. 

How do we justify the apparent lack of interoperability between different event specs with Stephen on this one? I suspect while I (editor) may let it go that he will not. 

The best justification argument I think is that when they match, an event can short cut by having one iss value to avoid duplication. 

But that still leaves 4 different resulting formats.

Why not just make all events to provide a fully qualified sub value?  OIDC can use iss/sub as their value. 

Phil

> On Mar 9, 2017, at 10:49 AM, Mike Jones <[email-masked]> wrote:
> 
> One use case for which there is only a single issuer and a single subject is common and straightforward.  One example is when an Identity Provider is authoritative for a digital identity that it is the issuer for.  That IdP can issue events about that digital identity.  I’ll note that OpenID Connect uses are of this kind, and that the “sub” value is relative to the issuer – not globally unique.  Trying to make “sub” globally unique would be a breaking change.
>  
>                                                        -- Mike
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 9 Mar 2017 19:13:49 +0000

What fully qualified “sub” value would you even recommend in the Connect case?  Creating a different “sub” value than the Connect-defined one that would only be ignored can’t help interop.  This violates the principle of keeping the simple cases simple.

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Thursday, March 9, 2017 11:10 AM
To: Mike Jones <[email-masked]>
Cc: Benjamin Kaduk <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Phil

On Mar 9, 2017, at 10:49 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
One use case for which there is only a single issuer and a single subject is common and straightforward.  One example is when an Identity Provider is authoritative for a digital identity that it is the issuer for.  That IdP can issue events about that digital identity.  I’ll note that OpenID Connect uses are of this kind, and that the “sub” value is relative to the issuer – not globally unique.  Trying to make “sub” globally unique would be a breaking change.

                                                       -- Mike

Sorry for the delay.

-Ben

Phil

                                                       -- Mike

   {

   {

     "sub": "248289761001",
     "iat": 1458496025,

   {

Would it be possible for events to require that “sub” be globally unique — e.g. expressed as a url.  For example, in order for backchannel to be issued by an OP or an RP, it would be expressed with sub as a URL ("sub": “https://server.example.com/248289761001<https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_248289761001&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=5Rnz1dzOEoK27YDktq_HMGneutBpDod8-iAqU1CgizQ&e=>”,):
   {
      "iss": "https://www.exampleapp.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.exampleapp.com_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=KuoD7Qelh1vowEZDz-WSjpIwC7vlR410B8RPsdfQg20&e=>",
      "sub": “https://server.example.com/248289761001<https://urldefense.proofpoint.com/v2/url?u=https-3A__server.example.com_248289761001&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=5Rnz1dzOEoK27YDktq_HMGneutBpDod8-iAqU1CgizQ&e=>",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout<https://urldefense.proofpoint.com/v2/url?u=http-3A__schemas.openid.net_event_backchannel-2Dlogout&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=OndKKucFPayCxClqGiVktItU3lmkVkSzQBxUvBmLEik&s=qmlNwMQZyc4wKMGYlcbHv4N_qYgxNWYhJxV9x_obkMQ&e=>": {}
      }

Phil

+1

-Ben

Id-event mailing list

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 9 Mar 2017 12:06:24 -0800

Mike

For give me but I think 4 different formats does not strike some as simple. Never the less to do you believe it will get past the iesg?

I am happy to leave it but suspect we will get blocked later on without good text. 

Phil

> On Mar 9, 2017, at 11:13 AM, Mike Jones <[email-masked]> wrote:
>

---

From: Mike Jones <[email-masked]>
Date: Thu, 9 Mar 2017 20:28:22 +0000

I’d be glad to work with you on text intended to help readers understand the intent.  I think it would help to have a clear statement along the lines of “Each Profile Specification defining an event or events specifies which claims are used with the events defined, and how they are used, subject to the events conforming to the constraints in the “Core SET Claims” section”.  That’s always been true throughout the design, but it will probably help to say so explicitly.

We do say in the “sub” claim description “If used, the Profile Specification SHOULD define the content and format semantics for the value.”  This is actually true of all claims used with the event – not only the “sub” claim.  That’s the kind of thing I was getting at.

                                                       Cheers,
                                                       -- Mike

Sent: Thursday, March 9, 2017 12:06 PM

Mike

Phil

On Mar 9, 2017, at 11:13 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
What fully qualified “sub” value would you even recommend in the Connect case?  Creating a different “sub” value than the Connect-defined one that would only be ignored can’t help interop.  This violates the principle of keeping the simple cases simple.

Cc: Benjamin Kaduk <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>

Phil

                                                       -- Mike

Sorry for the delay.

-Ben

Phil

                                                       -- Mike

   {

   {

     "sub": "248289761001",
     "iat": 1458496025,

   {

Phil

+1

-Ben

Id-event mailing list

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 9 Mar 2017 12:59:09 -0800

I agree with the text on sub. 

The problem is the conflict around "iss" being part of the subject issuer vs the event issuer. 

One iss can be used for both sub and event when the same.... but, because they often different all parsers have to check multiple locations in case they are. If they didn't check the event would have a different meaning. 

What seems easy for the asserter is complex logic for the receiver. 

The complexity being that parsers MUST always check all possible places (which will vary by spec) to see if an override iss is present. They cannot reliably stop at the first instance of iss they have to check for a nested iss. 

Phil

> On Mar 9, 2017, at 12:28 PM, Mike Jones <[email-masked]> wrote:
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 10 Mar 2017 16:26:44 -0600

I had to think a bit about why this didn't feel quite right to me.  I
think it's that I wasn't sure how the event consumer would know that the
(event) issuer is such an authoritative IdP.  Looking later in the
thread, it sounds like maybe the profile specification will make that
clear; is that the case?

Thanks,

Ben

On 03/09/2017 12:49 PM, Mike Jones wrote:
>
> One use case for which there is only a single issuer and a single
> subject is common and straightforward.  One example is when an
> Identity Provider is authoritative for a digital identity that it is
> the issuer for.  That IdP can issue events about that digital
> identity.  I’ll note that OpenID Connect uses are of this kind, and
> that the “sub” value is relative to the issuer – not globally unique. 
> Trying to make “sub” globally unique would be a breaking change.
>
>  
>
>                                                        -- Mike
>
>  
>
> *Sent:* Wednesday, March 8, 2017 3:47 PM
> *To:* Phil Hunt <[email-masked]>; Mike Jones
> <[email-masked]>
>     Just to be clear. You are expressing a perspective of maintaining
>     the exact format as defined by the ID Token and imposing the limit
>     on all other Events.  
>
>      
>
>     If I understand correctly, JWT (RFC7519) has no such limitation on
>     sub and the group *could* choose to profile “sub” to be globally
>     unique for all SET Events. Correct?
>
>      
>
>     identification formats already in the spec and to ask, is this
>     really acceptable (per Yaron’s request)?
>
>      
>
> My preference would be your "4th option" to always have "sub" and
> "iss" in the events payload, even if "iss" is the same in the outer
> envelope and the events payload -- it's unambiguous and easy to
> interpret.  Mike has mostly convinced me that there exist environments
> when the two "iss" are absolutely required to be identical and are
> strictly duplicated (which lends itself naturally to the status quo). 
> But since I don't understand these cases very well, I'm concerned
> about how to identify those environments and whether there would be
> interop issues if such an environment contained an actor that also had
> to interact with a more generic environment.
>
>
>     My concern is that we are too compatible with existing code. SETs
>     can easily be confused as ID Tokens as existing ID Token parsers
>     will ignore the events attribute and will see all the normal
>     claims for an ID Token as being present.  If you can address this,
>     then I can live with the status quo.
>
>      
>
>
>     Are they any that have issues with the current draft (in order to
>     get back to Yaron’s question)? The current draft allows multiple
>     iss values to appear in different places in the JSON structure
>     based on profiling specification definition.
>
>      
>
>     Phil
>
>      
>
>         because for important use cases, it’s relative to the issuer. 
>         Trying to force it to be a URI would unnecessarily limit the
>         applicability of the SET spec, causing some applications to
>         simply decide to not use it as a result.
>
>          
>
>         If some use cases want a kind of logout event that’s issued by
>         a different party than the IdP, then the current spec lets
>         that new event be defined.  It will require more parameters
>         than the current logout event, but that’s OK, since it’s used
>         in different contexts.
>
>          
>
>         In my view, it’s not editorially lazy to allow events to
>         define what claims they need.  It’s an intentional choice,
>         which enables the simple cases to be simply expressed, while
>         also enabling more complicated cases carrying more information
>         to be expressed.
>
>          
>
>         Trying to force the simple events use extra syntax only
>         actually needed for complicated events would be a severe
>         architectural mistake on our part.
>
>          
>
>                                                                -- Mike
>
>          
>
>         *Subject:* Re: [Id-event] Thread: Clarifying use of sub and
>         iss in SET tokens
>
>          
>
>          
>
>         As editor, my feeling is we have no *clean* or *simple*
>         solution because we have to use “iss” to mean the issuer of
>         the SET in order to comply with JWT and because OIDC conflates
>         assertion issuer with subject issuer, it makes it difficult to
>         uniquely identify a “sub” value because some events want to
>         use “iss” for 2 purposes (to identify the event issuer vs. the
>         subject issuer).
>
>          
>
>         None of the solutions presented are actually easy to explain.
>         So far, I’ve sided with Mike and William because they feel it
>         is close enough and it was editorially lazy (say nothing). I
>         am worried that this is actually complex for developers who do
>         not know the history of how JWTs emerged.
>
>          
>
>         current draft, there are 3 separate ways of expressing the
>         subject of an event….
>
>          
>
>         Scenario 2, a relying party is issuing an event, event iss and
>         sub iss are different and thus there are repeat iss values:
>
>          
>
>            {
>
>              "sub":
>         "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9
>         I believe the current argument is that profiling specs
>         explains how their events are to be parsed. This means for
>         multi-event parsers, subject is inconsistent and potentially
>         not mappable.  The BackChannel Logout event is currently
>         structured for only the OP to issue. However Oracle wants that
>         to be bi-directional so that web sites can notify the IDP/OP
>         that the user has logged out of a specific web site.  If that
>         happens, BackChannel logout will have methods 1 and 2 required.
>
>          
>
>         Would it be possible for events to require that “sub” be
>         globally unique — e.g. expressed as a url.  For example, in
>         order for backchannel to be issued by an OP or an RP, it would
>         be expressed with sub as a URL ("sub":
>         “https://server.example.com/248289761001
>         At least this way iss is never duplicated and sub is always
>         the addressable subject of the event regardless of the type of
>         event.  That would enable all 3 cases to be expressed one way
>         for all specs.  That seems simple to me (at least from how I
>         would define this in the spec).  
>
>          
>
>         I had thought Justin was advocating a 4th option which is to
>         always embed “sub” and “iss” in the event payload.  So you
>         would end up with something like:
>
>            {
>
>         Note that in the above example, “iss” would always be present
>         even if “iss” is the *same*.  The rule would be that the iss
>         and sub are in the payload and that addresses the subject of
>         the event. The envelope level is always reserved for event
>         validation and addressing only.  While some would argue this
>         is ugly, I can see some merits as it is at least consistent.
>
>          
>
>          
>
>         Phil
>
>          
>
>                     Justin, I suspect you didn’t see my earlier reply
>                     to Phil’s note that you also replied to, so I’m
>                     repeating it here and sending it to you directly. 
>                     (It wouldn’t be the first time that DMARC policies
>                     caused some of my contributions to be not received
>                     by some participants. :-( )
>
>                      
>
>                     Agreed that this is unclear.  Duplicating
>                     information in a protocol **always** introduces an
>                     unnecessary error case – the need to define how to
>                     handle the situation in which two pieces of
>                     information that are required to be identical are
>                     different.  Information in a SET should occur at
>                     most once.
>
>                      
>
>
>                 That seems a dangerous road to tread, as it requires
>                 care in defining "information" -- duplicating the same
>                 data strings at different levels of the hierarchy of a
>                 JSON object may very well not be duplicating
>                 information, due to the extra context provided by the
>                 hierarchy.  In my mind, it's not a clear case that you
>                 should never send the same name/value multiple times
>                 in different parts of an object, as sometimes it is
>                 good to keep the semantic separation clear.
>
>                 -Ben
>
>              
>
>          
>
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=Ma3MDbWVFnIyFGL2K_OCpMN37A8gsJRuyz6AIcbA7TA&s=og1z-m3kp2hcMYwqmJGL_8FwUfmQRoyAMzwqOCfMz1E&e=>
>
>  
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 10 Mar 2017 22:29:55 +0000

Yes, the profiling spec needs to define the claims usage for the event.  This is one example of the application of that rule.

From: Benjamin Kaduk [mailto:[email-masked]]
Sent: Friday, March 10, 2017 2:27 PM
To: Mike Jones <[email-masked]>; Phil Hunt <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

I had to think a bit about why this didn't feel quite right to me.  I think it's that I wasn't sure how the event consumer would know that the (event) issuer is such an authoritative IdP.  Looking later in the thread, it sounds like maybe the profile specification will make that clear; is that the case?

Thanks,

Ben

                                                       -- Mike

From: Benjamin Kaduk [mailto:[email-masked]]
Sent: Wednesday, March 8, 2017 3:47 PM
To: Phil Hunt <[email-masked]><mailto:[email-masked]>; Mike Jones <[email-masked]><mailto:[email-masked]>
Cc: ID Events Mailing List <[email-masked]><mailto:[email-masked]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

Sorry for the delay.

-Ben

Phil

                                                       -- Mike

   {

   {

     "sub": "248289761001",
     "iat": 1458496025,

   {

Phil

+1

-Ben

Id-event mailing list

https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=Ma3MDbWVFnIyFGL2K_OCpMN37A8gsJRuyz6AIcbA7TA&s=og1z-m3kp2hcMYwqmJGL_8FwUfmQRoyAMzwqOCfMz1E&e=>