Subject: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

From: Marius Scurtescu <[email-masked]>
Date: Thu, 8 Jun 2017 18:28:16 -0700

There were a couple of proposals on how to distinguish SETs from Id Tokens
and Access Tokens in such a way that naive implementations will not confuse
one for the other and open up security vulnerabilities.

There is also another important requirement: the SET issuer in some cases
must be different from the "sub" issuer. This is the case of an RP sending
SETs to an IdP.

With these requirements in mind I propose the following:
- both "sub" and "iss" to be defined at the event level
- "iss" at event level and at top SET level can be different
- "iss" and "sub" at event level can be different across events in the same
SET
- "sub" should NOT be present at the top SET level (this solves the
disambiguation), please note "should" and not "must"

This solution also allows different profiles that define event types to
define additional claims related to sub (like email or phone_number) and
since all these claims will be at the event level there will be no
collisions or ambiguity.

Another proposal (which I supported) was to define a composite "aud" claim.
This is not solving the requirement for a distinct  SET issuer. Also,
having the same claim name having different syntax in different token types
could lead to confusion.

And yet another proposal was to introduce a new claim for JWTs that defines
a "type". This is not practical in the short term, and it also is not
solving the distinct issuer requirement, but I think this is something the
JWT group should seriously consider.

Thoughts?

Marius

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 8 Jun 2017 18:32:12 -0700

+1

Phil

> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> There were a couple of proposals on how to distinguish SETs from Id Tokens and Access Tokens in such a way that naive implementations will not confuse one for the other and open up security vulnerabilities.
> 
> There is also another important requirement: the SET issuer in some cases must be different from the "sub" issuer. This is the case of an RP sending SETs to an IdP.
> 
> - "iss" and "sub" at event level can be different across events in the same SET
> - "sub" should NOT be present at the top SET level (this solves the disambiguation), please note "should" and not "must"
> 
> This solution also allows different profiles that define event types to define additional claims related to sub (like email or phone_number) and since all these claims will be at the event level there will be no collisions or ambiguity.
> 
> Another proposal (which I supported) was to define a composite "aud" claim. This is not solving the requirement for a distinct  SET issuer. Also, having the same claim name having different syntax in different token types could lead to confusion.
> 
> And yet another proposal was to introduce a new claim for JWTs that defines a "type". This is not practical in the short term, and it also is not solving the distinct issuer requirement, but I think this is something the JWT group should seriously consider.
> 
> Thoughts?
> 
> Marius
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=

---

From: "matake, nov" <[email-masked]>
Date: Fri, 9 Jun 2017 10:56:09 +0900

+1 especially for "type"

2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) <[email-masked]>:

> > There were a couple of proposals on how to distinguish SETs from Id
> Tokens and Access Tokens in such a way that naive implementations will not
> confuse one for the other and open up security vulnerabilities.
> >
> > There is also another important requirement: the SET issuer in some
> cases must be different from the "sub" issuer. This is the case of an RP
> sending SETs to an IdP.
> >
> > Another proposal (which I supported) was to define a composite "aud"
> claim. This is not solving the requirement for a distinct  SET issuer.
> Also, having the same claim name having different syntax in different token
> types could lead to confusion.
> >
> > And yet another proposal was to introduce a new claim for JWTs that
> defines a "type". This is not practical in the short term, and it also is
> not solving the distinct issuer requirement, but I think this is something
> the JWT group should seriously consider.
> >
> > Thoughts?
> >
> > Marius
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_
> jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=
>
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Adam Dawes <[email-masked]>
Date: Fri, 09 Jun 2017 04:02:00 +0000

I was initially a fan of keeping SETS to be very similar to id tokens but I
now think this is a better plan.

-- 
Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410

---

From: Dick Hardt <[email-masked]>
Date: Fri, 09 Jun 2017 04:59:30 +0000

Yaron, Mike and I just published an BCP ID for JWT
http://self-issued.info/?p=1690

On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <[email-masked]> wrote:

> I was initially a fan of keeping SETS to be very similar to id tokens but
> I now think this is a better plan.
>
>>> > This solution also allows different profiles that define event types
>>> to define additional claims related to sub (like email or phone_number) and
-- 
Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about
projects I am working on!

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 12 Jun 2017 15:15:37 -0700

Thanks for the pointer Dick, very good timing :-)

The issue is described by "2.7. Cross-JWT Confusion" and the mitigation is
in "3.9. Use Mutually Exclusive Validation Rules for Different Kinds of
JWTs", specifically "Use different sets of required claims...", "Use
different keys for different kinds of JWTs." and "Use different issuers for
different kinds of JWTs.".

I still think that a "type" claim would bring a lot of clarity and safety.

Marius

On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <[email-masked]> wrote:

>> <(650)%20214-2410>
> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn
> about projects I am working on!
>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 12 Jun 2017 15:18:43 -0700

Agreed. Note that there is still lots of discussion on what should be in
3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <[email-masked]>
wrote:

>>> I was initially a fan of keeping SETS to be very similar to id tokens
>>> but I now think this is a better plan.
>>>
>>>>> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>>>>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>>>>> lZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivz
>>>>> jWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqm
>>>>> g&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=
>>>>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 12 Jun 2017 23:01:44 +0000

Thanks for putting this together!

I think the assumptions inherent in 3.9 are flawed:

·         We can’t guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a “fail on an unrecognized claim” approach to ensure that JWTs from some future spec can’t be mistaken for JWTs from a current spec.

·         It is unrealistic to expect implementers to adhere to the “different keys for different kinds of JWTs” rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.

·         Ditto for “aud” and “iss” claims.

+1 for a “type” or “usage” claim/header parameter.

--
Annabelle Richard Backman
Identity Services

From: Id-event <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Monday, June 12, 2017 at 3:18 PM
To: Marius Scurtescu <[email-masked]>
Cc: Adam Dawes <[email-masked]>, "matake, nov" <[email-masked]>, ID Events Mailing List <[email-masked]>, "Phil Hunt (IDM)" <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Agreed. Note that there is still lots of discussion on what should be in 3.9.

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for the pointer Dick, very good timing :-)

The issue is described by "2.7. Cross-JWT Confusion" and the mitigation is in "3.9. Use Mutually Exclusive Validation Rules for Different Kinds of JWTs", specifically "Use different sets of required claims...", "Use different keys for different kinds of JWTs." and "Use different issuers for different kinds of JWTs.".

Marius

On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Yaron, Mike and I just published an BCP ID for JWT http://self-issued.info/?p=1690

On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <[email-masked]<mailto:[email-masked]>> wrote:
I was initially a fan of keeping SETS to be very similar to id tokens but I now think this is a better plan.

On Thu, Jun 8, 2017 at 6:56 PM matake, nov <[email-masked]<mailto:[email-masked]>> wrote:
+1 especially for "type"

2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>:
+1

Phil

> On Jun 8, 2017, at 6:28 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
>
> [email-masked]<mailto:[email-masked]>

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

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event
--
Adam Dawes | Sr. Product Manager | [email-masked]<mailto:[email-masked]> | +1 650-214-2410<tel:(650)%20214-2410>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event
--
Subscribe to the HARDTWARE<http://hardtware.com/> mail list to learn about projects I am working on!

--
Subscribe to the HARDTWARE<http://hardtware.com/> mail list to learn about projects I am working on!

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 13 Jun 2017 11:09:52 +0200

Hello,

quick question.

Are you thinking about a more traditional content-type or an 
information-type as can be found in:

> https://tools.ietf.org/html/draft-ietf-mile-rolie-07#section-7.1.2

Viele Grüße,

Henk

On 06/13/2017 01:01 AM, Richard Backman, Annabelle wrote:
> ·We can’t guarantee that every type of JWT will have a mutually 
> exclusive set of valid claims and/or header parameters, and enforcing 
> this requires a “fail on an unrecognized claim” approach to ensure that 
> JWTs from some future spec can’t be mistaken for JWTs from a current spec.
> 
> ·It is unrealistic to expect implementers to adhere to the “different 
> keys for different kinds of JWTs” rule. Whether mandated by the spec or 
> not, implementers will ignore this because managing one key is easier 
> than managing N different keys.
> 
> ·Ditto for “aud” and “iss” claims.
> 
> *From: *Id-event <[email-masked]> on behalf of Dick Hardt 
> <[email-masked]>
> *Date: *Monday, June 12, 2017 at 3:18 PM
> *To: *Marius Scurtescu <[email-masked]>
> *Cc: *Adam Dawes <[email-masked]>, "matake, nov" <[email-masked]>, ID 
> Events Mailing List <[email-masked]>, "Phil Hunt (IDM)" 
> <[email-masked]>
> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and 
> distinct SET issuer
> 
>     The issue is described by "2.7. Cross-JWT Confusion" and the
>     mitigation is in "3.9. Use Mutually Exclusive Validation Rules for
>     Different Kinds of JWTs", specifically "Use different sets of
>     required claims...", "Use different keys for different kinds of
>     JWTs." and "Use different issuers for different kinds of JWTs.".
> 
>             I was initially a fan of keeping SETS to be very similar to
>             id tokens but I now think this is a better plan.
> 
>                 2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
>                 <[email-masked] <mailto:[email-masked]>>:
> 
>                     +1
> 
>                     Phil
> 
> 
>                      > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
>                     <[email-masked]
>                     <mailto:[email-masked]>> wrote:
>                      >
>                      > There were a couple of proposals on how to
>                     distinguish SETs from Id Tokens and Access Tokens in
>                     such a way that naive implementations will not
>                      > There is also another important requirement: the
>                     SET issuer in some cases must be different from the
>                     "sub" issuer. This is the case of an RP sending SETs
>                     to an IdP.
>                      >
>                      > - "sub" should NOT be present at the top SET
>                     level (this solves the disambiguation), please note
>                     "should" and not "must"
>                      >
>                      > This solution also allows different profiles that
>                     define event types to define additional claims
>                     related to sub (like email or phone_number) and
>                     since all these claims will be at the event level
>                     there will be no collisions or ambiguity.
>                      >
>                      > Another proposal (which I supported) was to
>                     define a composite "aud" claim. This is not solving
>                     the requirement for a distinct  SET issuer. Also,
>                     having the same claim name having different syntax
>                     in different token types could lead to confusion.
>                      >
>                      > And yet another proposal was to introduce a new
>                     claim for JWTs that defines a "type". This is not
>                     practical in the short term, and it also is not
>                     solving the distinct issuer requirement, but I think
>                     this is something the JWT group should seriously
>                     consider.
>                      >
>                      > Thoughts?
>                      >
>                      > Marius
> 
>                      > [email-masked] <mailto:[email-masked]>
>                      >
>                     [email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>
>             Adam Dawes | Sr. Product Manager [email-masked]
>             <mailto:[email-masked]> |+1 650-214-2410
>             <tel:(650)%20214-2410>
> 
>             [email-masked] <mailto:[email-masked]>
>         Subscribe to the HARDTWARE <http://hardtware.com/> mail list to
>         learn about projects I am working on!
> 
> 
> 
> -- 
>

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 13 Jun 2017 11:11:28 +0200

And a 2nd question.

What semantics would "usage" provide that that are not covered via 
"intend", "audience", and "scope"?

Henk

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 13 Jun 2017 09:11:56 -0700

Yes and no. We have an event type uri attribute that indicates content. It defines the type of event and enables a payload json object to be attached. 

IOW, SET's type Works  differently. 

Phil

> On Jun 13, 2017, at 2:11 AM, Henk Birkholz <[email-masked]> wrote:
> 
> And a 2nd question.
> 
> What semantics would "usage" provide that that are not covered via "intend", "audience", and "scope"?
> 
> Henk
> 
>> ·We can’t guarantee that every type of JWT will have a mutually exclusive set of valid claims and/or header parameters, and enforcing this requires a “fail on an unrecognized claim” approach to ensure that JWTs from some future spec can’t be mistaken for JWTs from a current spec.
>> ·It is unrealistic to expect implementers to adhere to the “different keys for different kinds of JWTs” rule. Whether mandated by the spec or not, implementers will ignore this because managing one key is easier than managing N different keys.
>> *From: *Id-event <[email-masked]> on behalf of Dick Hardt <[email-masked]>
>> *Cc: *Adam Dawes <[email-masked]>, "matake, nov" <[email-masked]>, ID Events Mailing List <[email-masked]>, "Phil Hunt (IDM)" <[email-masked]>
>> *Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer
>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>>        https://urldefense.proofpoint.com/v2/url?u=http-3A__self-2Dissued.info_-3Fp-3D1690&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=24GdxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=TmPWehBYcEv9H3-5mfe8VNG0PBvicrwhiIHAjmjxXPk&e=         On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <[email-masked]
>>        <mailto:[email-masked]>> wrote:
>>                    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=24GdxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=fA3RYdeEvTH-Q-h8EvUi4V7WR6ZfsiWdesV5yKZNS_Y&e=                 _______________________________________________
>>                Id-event mailing list
>>                https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=24GdxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=fA3RYdeEvTH-Q-h8EvUi4V7WR6ZfsiWdesV5yKZNS_Y&e=             --             Adam Dawes | Sr. Product Manager [email-masked]
>>            https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=24GdxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=fA3RYdeEvTH-Q-h8EvUi4V7WR6ZfsiWdesV5yKZNS_Y&e=         --         Subscribe to the HARDTWARE <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=24GdxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=hSH8aCPkZjcBfcg_w_nM1IYCgx_YdFa43z1GxgdiJNE&e= > mail list to
>> Subscribe to the HARDTWARE <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=24GdxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=hSH8aCPkZjcBfcg_w_nM1IYCgx_YdFa43z1GxgdiJNE&e= > mail list to learn about projects I am working on!
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=24GdxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=fA3RYdeEvTH-Q-h8EvUi4V7WR6ZfsiWdesV5yKZNS_Y&e= 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwIGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=24GdxYmg1CIzVq_K__5inaEWYG6ZrWzxu2Gu6_gAJ-0&s=fA3RYdeEvTH-Q-h8EvUi4V7WR6ZfsiWdesV5yKZNS_Y&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Tue, 13 Jun 2017 11:05:15 -0700

> "intend", "audience", and "scope"?

"aud" (audience) specifies the target client, but not the intended usage
(access token to authorize resource access or SET to communicate a security
event?)

"scope" is not used by SET.

I don't know what do you mean by "intend" (or intent)?

>> ·We can’t guarantee that every type of JWT will have a mutually exclusive
>> set of valid claims and/or header parameters, and enforcing this requires a
>> “fail on an unrecognized claim” approach to ensure that JWTs from some
>> future spec can’t be mistaken for JWTs from a current spec.
>>
>> not, implementers will ignore this because managing one key is easier than
>> managing N different keys.
>>
>> Events Mailing List <[email-masked]>, "Phil Hunt (IDM)" <
>> [email-masked]>
>>                     https://urldefense.proofpoint.
>> com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Dev
>> ent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&
>> r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp
>> 74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88
>> YKOCd0mxPQFJLhxWI&e=
>>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 14 Jun 2017 00:33:27 +0000

Echoing Marius’s question: can you explain what you mean by “intend”?

To your first question, I think a better analogy would be the X.509 Key Usage extension: a multi-valued property that declares the intended purpose of the JWT, and that a recipient may refer to when determining whether to accept a JWT being presented to it in some context.

From: Id-event <[email-masked]> on behalf of Marius Scurtescu <[email-masked]>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <[email-masked]<mailto:[email-masked]>> wrote:
And a 2nd question.

"aud" (audience) specifies the target client, but not the intended usage (access token to authorize resource access or SET to communicate a security event?)

Henk

--

Identity Services

*From: *Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked]<mailto:[email-masked]>>
*Date: *Monday, June 12, 2017 at 3:18 PM
*To: *Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
*Cc: *Adam Dawes <[email-masked]<mailto:[email-masked]>>, "matake, nov" <[email-masked]<mailto:[email-masked]>>, ID Events Mailing List <[email-masked]<mailto:[email-masked]>>, "Phil Hunt (IDM)" <[email-masked]<mailto:[email-masked]>>
*Subject: *Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    I still think that a "type" claim would bring a lot of clarity and
    safety.

    Marius

    On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

        On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <[email-masked]<mailto:[email-masked]>
        <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

            On Thu, Jun 8, 2017 at 6:56 PM matake, nov <[email-masked]<mailto:[email-masked]>
            <mailto:[email-masked]<mailto:[email-masked]>>> wrote:

                +1 especially for "type"

                2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
                <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>:

                    +1

                    Phil

                     > On Jun 8, 2017, at 6:28 PM, Marius Scurtescu
                    <[email-masked]<mailto:[email-masked]>
                    distinguish SETs from Id Tokens and Access Tokens in
                    such a way that naive implementations will not
                    confuse one for the other and open up security
                    vulnerabilities.

                     > [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
                     >

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

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

            --
            Adam Dawes | Sr. Product Manager [email-masked]<mailto:[email-masked]>
            <mailto:[email-masked]<mailto:[email-masked]>> |+1 650-214-2410<tel:%2B1%20650-214-2410>
            <tel:(650)%20214-2410>

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

--

Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn about projects I am working on!

---

From: Mike Jones <[email-masked]>
Date: Wed, 14 Jun 2017 20:16:42 +0000

You’ve heard of “premature optimization”.  I’d characterize the proposals in this thread as “premature pessimation” – making things that can and should be simple complex, without data showing there’s any need to do so.

Mandatory solutions are being proposed in this thread to problems that there’s no evidence that we actually even have.  It’s already been established that it’s impossible for a SET to be confused for an ID Token – see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html.  If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.

The proposed “solutions”, such as prohibiting the use of “sub” in the normal way, or requiring a type claim, would make previously simple things unnecessarily complex.  Yes, then the result is then different than a normal JWT but a consequence of this is that custom parsing code would have to be used, rather than a standard JWT parser.  The more unwieldy we make it to use SETs, the more likely developers are to just create their own data structures.  Keeping it simple is the key to adoption.  Standards are only useful if they are actually used.

                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Richard Backman, Annabelle
Sent: Tuesday, June 13, 2017 5:33 PM
To: Marius Scurtescu <[email-masked]>; Henk Birkholz <[email-masked]>
Cc: ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, June 13, 2017 at 11:05 AM
To: Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Cc: ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 15 Jun 2017 00:25:25 +0000

Mike,

Your explanation for why this is a non-problem is dependent upon side effects of elements of OpenID Connect that were not designed to solve this issue. As a result, I see several issues with it:

1.       The caller of the Token Endpoint is the only party that can be certain that a nonce-less ID Token is really an ID Token. Any party that the caller passes the ID Token off to has no way to verify its provenance.

2.       Any future ID Token distribution method needs to solve this problem again.

3.      No other profile of JWT can ever use the "nonce” claim.

4.      This is only a solution for ID Tokens. Every other JWT profile that cares about disambiguation has to invent its own solution to the problem.

We know from experience that naming collisions and replay attacks are both things that happen. What’s being proposed is a simple, defensive measure against these risks. You brought up JWT libraries: a general solution actually makes it easier to use common libraries for JWT parsing. A “usage-aware” JWT library could handle disambiguation for any JWT profile, whereas with the status quo each profile would require unique logic.

From: Id-event <[email-masked]> on behalf of Mike Jones <[email-masked]>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, ID Events Mailing List <[email-masked]>, Henk Birkholz <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 14 Jun 2017 17:33:12 -0700

+1

Phil

> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Mike,
>  
> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <[email-masked]> wrote:
> And a 2nd question.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 15 Jun 2017 10:09:48 -0700

+1 to what Annabelle said.

Also, Mike you are missing the other requirement, for RPs to send events to
an IdP. The iss+sub pair at the top level is broken in this case.

Marius

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

> Your explanation for why this is a non-problem is dependent upon side
> effects of elements of OpenID Connect that were not designed to solve this
> issue. As a result, I see several issues with it:
>
> 1.       The caller of the Token Endpoint is the only party that can be
> certain that a nonce-less ID Token is really an ID Token. Any party that
> the caller passes the ID Token off to has no way to verify its provenance.
>
> 4.      This is only a solution for ID Tokens. Every other JWT profile
> that cares about disambiguation has to invent its own solution to the
> problem.
>
>
>
> We know from experience that naming collisions and replay attacks are both
> things that happen. What’s being proposed is a simple, defensive measure
> against these risks. You brought up JWT libraries: a general solution
> actually makes it easier to use common libraries for JWT parsing. A
> “usage-aware” JWT library could handle disambiguation for any JWT profile,
> whereas with the status quo each profile would require unique logic.
>
>
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of Mike Jones <
> [email-masked]>
> *Date: *Wednesday, June 14, 2017 at 1:16 PM
> *Cc: *"Richard Backman, Annabelle" <[email-masked]>, ID Events
> Mailing List <[email-masked]>, Henk Birkholz <
> [email-masked]>
> You’ve heard of “premature optimization”.  I’d characterize the proposals
> in this thread as “premature pessimation” – making things that can and
> should be simple complex, without data showing there’s any need to do so.
>
>
>
> Mandatory solutions are being proposed in this thread to problems that
> there’s no evidence that we actually even have.  It’s already been
> established that it’s impossible for a SET to be confused for an ID Token –
> see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00428.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=eKLTQPmYrV3ThfDbn90SCs55UROTPin_lgc6Rdr5Xow&e=>.
> If people have data showing that this is possible with specific kinds of
> Access Tokens or other real JWT deployments, please provide specifics, so
> that we can use that data to inform appropriate engineering choices on our
> part.
>
>
>
> The proposed “solutions”, such as prohibiting the use of “sub” in the
> normal way, or requiring a type claim, would make previously simple things
> unnecessarily complex.  Yes, then the result is then different than a
> normal JWT but a consequence of this is that custom parsing code would have
> to be used, rather than a standard JWT parser.  The more unwieldy we make
> it to use SETs, the more likely developers are to just create their own
> data structures.  Keeping it simple is the key to adoption.  Standards are
> only useful if they are actually used.
>
>
>
>                                                 -- Mike
>
>
>
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Richard Backman, Annabelle
> *Sent:* Tuesday, June 13, 2017 5:33 PM
> *To:* Marius Scurtescu <[email-masked]>; Henk Birkholz <
> [email-masked]>
> *Cc:* ID Events Mailing List <[email-masked]>
> *Subject:* Re: [Id-event] solution for Id/Access Token confusion and
> distinct SET issuer
>
>
>
> To your first question, I think a better analogy would be the X.509 Key
> Usage extension: a multi-valued property that declares the intended purpose
> of the JWT, and that a recipient may refer to when determining whether to
> accept a JWT being presented to it in some context.
>
>
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of Marius
> Scurtescu <[email-masked]>
> *Date: *Tuesday, June 13, 2017 at 11:05 AM
> *To: *Henk Birkholz <[email-masked]>
> *Cc: *ID Events Mailing List <[email-masked]>
> ·It is unrealistic to expect implementers to adhere to the “different keys
> for different kinds of JWTs” rule. Whether mandated by the spec or not,
> implementers will ignore this because managing one key is easier than
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__self-2Dissued.info_-3Fp-3D1690&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=a7XvZ5jTbtA2vjfaHIMbvEOpSBBlBpdsDkITZMcUIUQ&e=>
>
> com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-
> 2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>
>             --
>             <tel:(650)%20214-2410 <(650)%20214-2410>>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>
>         --
>         Subscribe to the HARDTWARE <http://hardtware.com/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=i75Uw8aehYvlpIZNL7NxqGxhh1TOrQOUX2XMYBerV80&e=>>
> mail list to
> Subscribe to the HARDTWARE <http://hardtware.com/
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=i75Uw8aehYvlpIZNL7NxqGxhh1TOrQOUX2XMYBerV80&e=>>
> mail list to learn about projects I am working on!
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>
>
>
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
> Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=
> P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=
>
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 15 Jun 2017 15:08:26 -0400

+1 to this as well.

 — Justin

> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> Also, Mike you are missing the other requirement, for RPs to send events to an IdP. The iss+sub pair at the top level is broken in this case.
> 
> Marius
> 
> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> +1
> 
> Phil
> 
> On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Mike,
>> 
>>  
>> 
>> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Mike Jones <[email-masked] <mailto:[email-masked]>>
>> To: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>> Cc: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, ID Events Mailing List <[email-masked] <mailto:[email-masked]>>, Henk Birkholz <[email-masked] <mailto:[email-masked]>>
>> Mandatory solutions are being proposed in this thread to problems that there’s no evidence that we actually even have.  It’s already been established that it’s impossible for a SET to be confused for an ID Token – see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00428.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=eKLTQPmYrV3ThfDbn90SCs55UROTPin_lgc6Rdr5Xow&e=>.  If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.
>> 
>>  
>> 
>> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Richard Backman, Annabelle
>> To: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>; Henk Birkholz <[email-masked] <mailto:[email-masked]>>
>> Cc: ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
>> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>> To: Henk Birkholz <[email-masked] <mailto:[email-masked]>>
>> Cc: ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
>> On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> And a 2nd question.
>> 
>> *From: *Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Dick Hardt <[email-masked] <mailto:[email-masked]>>
>> *To: *Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>> *Cc: *Adam Dawes <[email-masked] <mailto:[email-masked]>>, "matake, nov" <[email-masked] <mailto:[email-masked]>>, ID Events Mailing List <[email-masked] <mailto:[email-masked]>>, "Phil Hunt (IDM)" <[email-masked] <mailto:[email-masked]>>
>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>>     On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>
>>     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>>         http://self-issued.info/?p=1690 <https://urldefense.proofpoint.com/v2/url?u=http-3A__self-2Dissued.info_-3Fp-3D1690&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=a7XvZ5jTbtA2vjfaHIMbvEOpSBBlBpdsDkITZMcUIUQ&e=>
>> 
>>         On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes <[email-masked] <mailto:[email-masked]>
>>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>>             On Thu, Jun 8, 2017 at 6:56 PM matake, nov <[email-masked] <mailto:[email-masked]>
>>             <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>> 
>>                 +1 especially for "type"
>> 
>>                 <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>:
>> 
>>                     +1
>> 
>>                     Phil
>> 
>> 
>>                     <[email-masked] <mailto:[email-masked]>
>>                     <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>                      >
>>                      > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>                      >
>>                     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=>
>> 
>>                     [email-masked] <mailto:[email-masked]> <mailto:[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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>> 
>>                 [email-masked] <mailto:[email-masked]> <mailto:[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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>> 
>>             -- 
>>             Adam Dawes | Sr. Product Manager [email-masked] <mailto:[email-masked]>
>>             <mailto:[email-masked] <mailto:[email-masked]>> |+1 650-214-2410 <tel:%2B1%20650-214-2410>
>>             <tel:(650)%20214-2410 <tel:(650)%20214-2410>>
>> 
>>             [email-masked] <mailto:[email-masked]> <mailto:[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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>> 
>>         -- 
>>         Subscribe to the HARDTWARE <http://hardtware.com/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=i75Uw8aehYvlpIZNL7NxqGxhh1TOrQOUX2XMYBerV80&e=>> mail list to
>> Subscribe to the HARDTWARE <http://hardtware.com/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=i75Uw8aehYvlpIZNL7NxqGxhh1TOrQOUX2XMYBerV80&e=>> mail list to learn about projects I am working on!
>> 
>> 
>> 
>> 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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>> 
>> 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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>>  
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=> 
>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 17 Jun 2017 23:45:06 +0300

So to summarize what I'm seeing on this thread:

Everybody agrees with Marius's short-term solution, specific rules for 
"sub" and "iss" that can be defined in the SET spec.

Almost everybody agrees on a long-term "usage" claim ("type" is taken) 
that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use it in the 
SET document before it is published.

Thanks,

     Yaron

On 15/06/17 22:08, Justin Richer wrote:
> +1 to this as well.
>
>  — Justin
>
>> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <[email-masked] 
>> Also, Mike you are missing the other requirement, for RPs to send 
>> events to an IdP. The iss+sub pair at the top level is broken in this 
>> case.
>>
>> Marius
>>
>> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     +1
>>
>>     Phil
>>
>>     On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>     Mike,
>>>
>>>     Your explanation for why this is a non-problem is dependent upon
>>>     side effects of elements of OpenID Connect that were not
>>>     designed to solve this issue. As a result, I see several issues
>>>     with it:
>>>
>>>     1.The caller of the Token Endpoint is the only party that can be
>>>     certain that a nonce-less ID Token is really an ID Token. Any
>>>     party that the caller passes the ID Token off to has no way to
>>>     verify its provenance.
>>>
>>>     2.Any future ID Token distribution method needs to solve this
>>>     problem again.
>>>
>>>     3.No other profile of JWT can ever use the "nonce” claim.
>>>
>>>     4.This is only a solution for ID Tokens. Every other JWT profile
>>>     that cares about disambiguation has to invent its own solution
>>>     to the problem.
>>>
>>>     We know from experience that naming collisions and replay
>>>     attacks are both things that happen. What’s being proposed is a
>>>     simple, defensive measure against these risks. You brought up
>>>     JWT libraries: a general solution actually makes it easier to
>>>     use common libraries for JWT parsing. A “usage-aware” JWT
>>>     library could handle disambiguation for any JWT profile, whereas
>>>     with the status quo each profile would require unique logic.
>>>
>>>     -- 
>>>
>>>     *From: *Id-event <[email-masked]
>>>     <mailto:[email-masked]>> on behalf of Mike Jones
>>>     <[email-masked] <mailto:[email-masked]>>
>>>     *Cc: *"Richard Backman, Annabelle" <[email-masked]
>>>     <mailto:[email-masked]>>, ID Events Mailing List
>>>     <[email-masked] <mailto:[email-masked]>>, Henk Birkholz
>>>     <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     You’ve heard of “premature optimization”.  I’d characterize the
>>>     proposals in this thread as “premature pessimation” – making
>>>     things that can and should be simple complex, without data
>>>     showing there’s any need to do so.
>>>
>>>     Mandatory solutions are being proposed in this thread to
>>>     problems that there’s no evidence that we actually even have. 
>>>     It’s already been established that it’s impossible for a SET to
>>>     be confused for an ID Token – see
>>>     https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html
>>>     If people have data showing that this is possible with specific
>>>     kinds of Access Tokens or other real JWT deployments, please
>>>     provide specifics, so that we can use that data to inform
>>>     appropriate engineering choices on our part.
>>>
>>>     The proposed “solutions”, such as prohibiting the use of “sub”
>>>     in the normal way, or requiring a type claim, would make
>>>     previously simple things unnecessarily complex.  Yes, then the
>>>     result is then different than a normal JWT but a consequence of
>>>     this is that custom parsing code would have to be used, rather
>>>     than a standard JWT parser. The more unwieldy we make it to use
>>>     SETs, the more likely developers are to just create their own
>>>     data structures.  Keeping it simple is the key to adoption. 
>>>     Standards are only useful if they are actually used.
>>>
>>>                       -- Mike
>>>
>>>     *From:*Id-event [mailto:[email-masked]
>>>     <mailto:[email-masked]>] *On Behalf Of *Richard
>>>     Backman, Annabelle
>>>     *To:* Marius Scurtescu <[email-masked]
>>>     <mailto:[email-masked]>>; Henk Birkholz
>>>     <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *Cc:* ID Events Mailing List <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *Subject:* Re: [Id-event] solution for Id/Access Token confusion
>>>     and distinct SET issuer
>>>
>>>     To your first question, I think a better analogy would be the
>>>     X.509 Key Usage extension: a multi-valued property that declares
>>>     the intended purpose of the JWT, and that a recipient may refer
>>>     to when determining whether to accept a JWT being presented to
>>>     it in some context.
>>>
>>>     -- 
>>>
>>>     *From: *Id-event <[email-masked]
>>>     <mailto:[email-masked]>> on behalf of Marius
>>>     Scurtescu <[email-masked] <mailto:[email-masked]>>
>>>     *To: *Henk Birkholz <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *Cc: *ID Events Mailing List <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     On Tue, Jun 13, 2017 at 2:11 AM, Henk Birkholz
>>>     <[email-masked]
>>>     <mailto:[email-masked]>> wrote:
>>>
>>>         And a 2nd question.
>>>
>>>         What semantics would "usage" provide that that are not
>>>         covered via "intend", "audience", and "scope"?
>>>
>>>     "aud" (audience) specifies the target client, but not the
>>>     intended usage (access token to authorize resource access or SET
>>>     to communicate a security event?)
>>>
>>>             ·We can’t guarantee that every type of JWT will have a
>>>             mutually exclusive set of valid claims and/or header
>>>             parameters, and enforcing this requires a “fail on an
>>>             unrecognized claim” approach to ensure that JWTs from
>>>             some future spec can’t be mistaken for JWTs from a
>>>             current spec.
>>>
>>>             ·It is unrealistic to expect implementers to adhere to
>>>             the “different keys for different kinds of JWTs” rule.
>>>             Whether mandated by the spec or not, implementers will
>>>             ignore this because managing one key is easier than
>>>             *From: *Id-event <[email-masked]
>>>             <mailto:[email-masked]>> on behalf of Dick
>>>             Hardt <[email-masked] <mailto:[email-masked]>>
>>>             *Cc: *Adam Dawes <[email-masked]
>>>             <mailto:[email-masked]>>, "matake, nov"
>>>             <[email-masked] <mailto:[email-masked]>>, ID Events
>>>             Mailing List <[email-masked]
>>>             <mailto:[email-masked]>>, "Phil Hunt (IDM)"
>>>             <[email-masked] <mailto:[email-masked]>>
>>>             On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu
>>>                 On Thu, Jun 8, 2017 at 9:59 PM, Dick Hardt
>>>             <[email-masked] <mailto:[email-masked]>
>>>                     On Thu, Jun 8, 2017 at 9:02 PM Adam Dawes
>>>             <[email-masked] <mailto:[email-masked]>
>>>                             <[email-masked]
>>>             <mailto:[email-masked]>
>>>             <mailto:[email-masked]
>>>             <mailto:[email-masked]>>>:
>>>
>>>                                 +1
>>>
>>>                                 Phil
>>>
>>>
>>>             <mailto:[email-masked]>
>>>
>>>             <mailto:[email-masked]> <mailto:[email-masked]
>>>             <mailto:[email-masked]>>
>>>                                  >
>>>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=JmuutBx4DAPp74AULcx2I_jvgXzua6miRiHqWgfxqmg&s=5xQqvBiXZ6Ij9NGDwVqXoVpn88YKOCd0mxPQFJLhxWI&e=>
>>>
>>>             <mailto:[email-masked] <mailto:[email-masked]>>
>>>             <mailto:[email-masked] <mailto:[email-masked]>>
>>>                         Adam Dawes | Sr. Product Manager
>>>             [email-masked] <mailto:[email-masked]>
>>>                         <mailto:[email-masked]
>>>             <mailto:[email-masked]>> |+1 650-214-2410
>>>             <tel:%2B1%20650-214-2410>
>>>                         <tel:(650)%20214-2410
>>>             <tel:%28650%29%20214-2410>>
>>>
>>>             <mailto:[email-masked] <mailto:[email-masked]>>
>>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>
>>>
>>
>>

---

From: Mike Jones <[email-masked]>
Date: Sat, 17 Jun 2017 21:06:52 +0000

I’m sorry to be slow replying to some messages in this thread.  I have a lot of other things on my plate, but I will take the time now to reply, because I wholeheartedly disagree with some of the statements below and believe it would be severely harmful to the specification and its adoption to act upon them.  Specifically:

  *   I disagree that specific rules should be made for the “sub” claim.  Claims usage needs to be up to the application.  I know that many others agree with me, because the OpenID Connect working group designed the logout token in http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken (which is also used as an example in https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2) to use the “sub” claim in the normal way.  Prohibiting this usage would be a completely unnecessary breaking change – as it’s impossible to confuse a logout token with an ID Token, for reasons already cites in this thread.

  *   (I agree with the “iss” rules already in place at https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1.  No further “iss” rules are needed.)

  *   It’s fine for the “typ” header parameter to be used for some profiles to differentiate between kinds of JWTs.  Its use should not be mandated in the SET spec.  I would oppose duplicating the “typ” functionality by defining another claim with a duplicative meaning.

  *   I’ll also respond to Annabelle’s assertion that “No other profile of JWT can ever use the "nonce” claim.”  This reflects a misunderstanding.  It’s the *value* of the nonce that self-secures the JWT – not that any “nonce” claim is present.  Any and all JWTs can simultaneously use “nonce” without any risk of conflict, since the nonce value is a cryptographically secure random number.

Will some of you be at the Cloud Identity Summit next week?  I’d be glad to have in-person discussions about these topics there.

                                                       -- Mike

P.S.  Food for thought:  Prohibiting the use of “sub” (or any other claim) or forcing it to be located in a non-standard location makes about as much sense as arbitrarily saying that, for a particular profile, the Latin word for subject “subiectum” must be used as the claim name instead of “sub”.  Yes, it will completely differentiate this profile from others not spelling the claim name this way, but it would certainly be an impediment to the use of standard JWT libraries and to interoperability.

From: Yaron Sheffer [mailto:[email-masked]]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <[email-masked]>; Marius Scurtescu <[email-masked]>
Cc: Richard Backman, Annabelle <[email-masked]>; Mike Jones <[email-masked]>; Henk Birkholz <[email-masked]>; ID Events Mailing List <[email-masked]>; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Everybody agrees with Marius's short-term solution, specific rules for "sub" and "iss" that can be defined in the SET spec.

Almost everybody agrees on a long-term "usage" claim ("type" is taken) that should be defined elsewhere, e.g. in the JWT BCP.

Did I miss anything?

By the way, if we do add a "usage" claim, we need to also use it in the SET document before it is published.

Thanks,

    Yaron

 — Justin

On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

Marius

On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
+1

Phil

On Jun 14, 2017, at 5:25 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
Mike,

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Mike Jones <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 14, 2017 at 1:16 PM
To: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, ID Events Mailing List <[email-masked]<mailto:[email-masked]>>, Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Mandatory solutions are being proposed in this thread to problems that there’s no evidence that we actually even have.  It’s already been established that it’s impossible for a SET to be confused for an ID Token – see https://www.ietf.org/mail-archive/web/id-event/current/msg00428.html<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00428.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=eKLTQPmYrV3ThfDbn90SCs55UROTPin_lgc6Rdr5Xow&e=>.  If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.

                                                -- Mike

To: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>

Henk

--

Identity Services

    Marius

        Yaron, Mike and I just published an BCP ID for JWT
        http://self-issued.info/?p=1690<https://urldefense.proofpoint.com/v2/url?u=http-3A__self-2Dissued.info_-3Fp-3D1690&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=a7XvZ5jTbtA2vjfaHIMbvEOpSBBlBpdsDkITZMcUIUQ&e=>

                +1 especially for "type"

                    +1

                    Phil

                    _______________________________________________
                    Id-event mailing list
                    [email-masked]<mailto:[email-masked]> <mailto:[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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>

                _______________________________________________
                Id-event mailing list
                [email-masked]<mailto:[email-masked]> <mailto:[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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>

            --
            Adam Dawes | Sr. Product Manager [email-masked]<mailto:[email-masked]>
            <mailto:[email-masked]<mailto:[email-masked]>> |+1 650-214-2410<tel:%2B1%20650-214-2410>
            <tel:(650)%20214-2410<tel:%28650%29%20214-2410>>

            _______________________________________________
            Id-event mailing list
            [email-masked]<mailto:[email-masked]> <mailto:[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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>

        --
        Subscribe to the HARDTWARE <http://hardtware.com/<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=i75Uw8aehYvlpIZNL7NxqGxhh1TOrQOUX2XMYBerV80&e=>> mail list to
        learn about projects I am working on!

--

Subscribe to the HARDTWARE <http://hardtware.com/<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=i75Uw8aehYvlpIZNL7NxqGxhh1TOrQOUX2XMYBerV80&e=>> mail list to learn about projects I am working on!

_______________________________________________
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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>

_______________________________________________
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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=>

Id-event mailing list

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Sat, 17 Jun 2017 14:46:48 -0700

Comments in line. 

Phil

> On Jun 17, 2017, at 2:06 PM, Mike Jones <[email-masked]> wrote:
> 
> I disagree that specific rules should be made for the “sub” claim.  Claims usage needs to be up to the application.  I know that many others agree with me, because the OpenID Connect working group designed the logout token in http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken (which is also used as an example in https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2) to use the “sub” claim in the normal way.  Prohibiting this usage would be a completely unnecessary breaking change – as it’s impossible to confuse a logout token with an ID Token, for reasons already cites in this thread.

Mike we disagree on this. 

I and others voted against the OpenId decision to move to implementer status of OpenId because of this issue and others. Chiefly that secevents had open issues that would cause breaking changes.  

You indicated at OpenId as secretary that breaking changes by secevents would NOT be an issue. 

We also disagree on the scope of use in logout. Recently you indicated we should define yet another logout. 

>  
> (I agree with the “iss” rules already in place at https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1.  No further “iss” rules are needed.)

It is still an issue that issuer of the subject vs issuer of the token are confused. 

We have this issue in ietf and openid as far as I am concerned because we have cases that will issue app logout notices that are fyi's to the idp. Eg app logout vs sso logout. 

If an app logs out the OP needs to know that the old id token is no good. 

>  
> It’s fine for the “typ” header parameter to be used for some profiles to differentiate between kinds of JWTs.  Its use should not be mandated in the SET spec.  I would oppose duplicating the “typ” functionality by defining another claim with a duplicative meaning.
>  
> I’ll also respond to Annabelle’s assertion that “No other profile of JWT can ever use the "nonce” claim.”  This reflects a misunderstanding.  It’s the *value* of the nonce that self-secures the JWT – not that any “nonce” claim is present.  Any and all JWTs can simultaneously use “nonce” without any risk of conflict, since the nonce value is a cryptographically secure random number.
>  
> On Wed, Jun 14, 2017 at 5:33 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> +1
>  
> Phil
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=WPqIpmdKcdpKZXupMf-xibi5O-t0ZuRpllAzZI6rgjQ&s=1XTj1kjyTq7Pz-UjTZmzMyJcVzl1sDGI55seqd9eVfs&e=

---

From: Mike Jones <[email-masked]>
Date: Sat, 17 Jun 2017 22:00:02 +0000

Replies inline marked with Mike>…

From: Phil Hunt (IDM) [mailto:[email-masked]]
Sent: Saturday, June 17, 2017 2:47 PM
To: Mike Jones <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; Justin Richer <[email-masked]>; Marius Scurtescu <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; Henk Birkholz <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Comments in line.

Phil

On Jun 17, 2017, at 2:06 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I’m sorry to be slow replying to some messages in this thread.  I have a lot of other things on my plate, but I will take the time now to reply, because I wholeheartedly disagree with some of the statements below and believe it would be severely harmful to the specification and its adoption to act upon them.  Specifically:

  *   I disagree that specific rules should be made for the “sub” claim.  Claims usage needs to be up to the application.  I know that many others agree with me, because the OpenID Connect working group designed the logout token in http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0-2D04.html-23LogoutToken&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=WPqIpmdKcdpKZXupMf-xibi5O-t0ZuRpllAzZI6rgjQ&s=BixvZyWpR90xFd3HEf4p1gK5ShH-dz-aF0cCU8bkGVg&e=> (which is also used as an example in https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D01-23section-2D2&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=WPqIpmdKcdpKZXupMf-xibi5O-t0ZuRpllAzZI6rgjQ&s=iW-7ReKFzOLCrA56Qs6EzS_Kxz5HajRyoz9KKhbXBOM&e=>) to use the “sub” claim in the normal way.  Prohibiting this usage would be a completely unnecessary breaking change – as it’s impossible to confuse a logout token with an ID Token, for reasons already cites in this thread.

Mike>  Yes, the working group can decide to make breaking changes.  It can also decide not to.  OpenID Connect has succeeded (at least in part) because it has kept simple things simple.  I will continue to be a tireless advocate for that design principle, including for SET.

Mike>  What I said in the conversation you’re referring to is that a logout event that’s always sent from the IdP to a RP is more specific than one that might be sent from anyone to anyone else.  The latter needs more information, and so could be defined for those additional use cases, if needed.  The OpenID Back-Channel logout case is the former, and so includes exactly the information necessary for that use case.

  *

  *   (I agree with the “iss” rules already in place at https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D01-23section-2D2.1&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=WPqIpmdKcdpKZXupMf-xibi5O-t0ZuRpllAzZI6rgjQ&s=R_IQ8DO5CFRNqhCjHiHSirwvTHGlNTkxMJfLjfwtcvY&e=>.  No further “iss” rules are needed.)

Mike>  The SET spec already says that the top-level “iss” claim refers to the event issuer.  There’s already no ambiguity, so no change is needed.

Mike> There’s already a message defined for that use case that’s in production use.  See https://openid.net/specs/openid-connect-session-1_0.html#RPLogout.  No additional protocol work is needed to achieve this.

  *

                                                       -- Mike

From: Yaron Sheffer [mailto:[email-masked]]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Did I miss anything?

Thanks,

    Yaron

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

_______________________________________________
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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=WPqIpmdKcdpKZXupMf-xibi5O-t0ZuRpllAzZI6rgjQ&s=1XTj1kjyTq7Pz-UjTZmzMyJcVzl1sDGI55seqd9eVfs&e=>

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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=WPqIpmdKcdpKZXupMf-xibi5O-t0ZuRpllAzZI6rgjQ&s=1XTj1kjyTq7Pz-UjTZmzMyJcVzl1sDGI55seqd9eVfs&e=>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Jun 2017 11:57:43 -0700

On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <[email-masked]>
wrote:

> I’m sorry to be slow replying to some messages in this thread.  I have a
> lot of other things on my plate, but I will take the time now to reply,
> because I wholeheartedly disagree with some of the statements below and
> believe it would be severely harmful to the specification and its adoption
> to act upon them.  Specifically:
>
>
>
>    - I disagree that specific rules should be made for the “sub” claim.
>    Claims usage needs to be up to the application.  I know that many others
>    agree with me, because the OpenID Connect working group designed the logout
>    token in http://openid.net/specs/openid-connect-backchannel-1_
>    0-04.html#LogoutToken (which is also used as an example in
>    https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2
>    <https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2>)
>    to use the “sub” claim in the normal way.  Prohibiting this usage would be
>    a completely unnecessary breaking change – as it’s impossible to confuse a
>    logout token with an ID Token, for reasons already cites in this thread.
>
> Solving the confusion is one problem. The other problem I keep mentioning
is SETs issued by an RP to be sent to an IdP. How are we solving that
problem Mike? In this case the top level iss is different from the iss of
the sub, a top level sub is not possible.

And I don't want to downplay the confusion problem either. I think it is a
real concern and I think a solid solution is important.

The OpenID Working Group designed logout tokens without secevent in mind. I
agree we should not recklessly break compatibility, but to me it seems
necessary in this case.

>
>    -
>
>
>
>    - (I agree with the “iss” rules already in place at
>    https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1
>    <https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1>.
>    No further “iss” rules are needed.)
>
>
Further iss ruies are absolutely needed for the RP to IdP case described
above.

>
>    -
>
>
>
>    - It’s fine for the “typ” header parameter to be used for some
>    profiles to differentiate between kinds of JWTs.  Its use should not be
>    mandated in the SET spec.  I would oppose duplicating the “typ”
>    functionality by defining another claim with a duplicative meaning.
>
> If typ can be use and no other claim is needed, then let's talk about
that. I do think SET should mandate it. I don't understand why not. Can you
please propose with examples how can typ be used?

>
>    -
>
>
>
>    - I’ll also respond to Annabelle’s assertion that “No other profile of
>    JWT can ever use the "nonce” claim.”  This reflects a
>    misunderstanding.  It’s the **value** of the nonce that self-secures
>    the JWT – not that any “nonce” claim is present.  Any and all JWTs can
>    simultaneously use “nonce” without any risk of conflict, since the nonce
>    value is a cryptographically secure random number.
>
>
For SETs I cannot see how the nonce value is useful. That value is not
passed back and it cannot be verified. Only the presence of the claim could
have some use, hinting at the usage of the JWT, a very weak solution to the
confusion problem.

>
>    -
>
>
>
> Will some of you be at the Cloud Identity Summit next week?  I’d be glad
> to have in-person discussions about these topics there.
>
>
>
>                                                        -- Mike
>
>
>
> P.S.  Food for thought:  Prohibiting the use of “sub” (or any other claim)
> or forcing it to be located in a non-standard location makes about as much
> sense as arbitrarily saying that, for a particular profile, the Latin word
> for subject “subiectum” must be used as the claim name instead of “sub”.
> Yes, it will completely differentiate this profile from others not spelling
> the claim name this way, but it would certainly be an impediment to the use
> of standard JWT libraries and to interoperability.
>

If we define that sub must be at the event level then it is at a standard
location, I don't see what the issue is. The impediment you mention is the
actual solution. I don't think that a JWT library that was written for Id
Tokens should be used to parse SETs. The library has to be SET aware, in
which case the event level iss+sub is not an issue at all.

>
>
> *From:* Yaron Sheffer [mailto:[email-masked]]
> *Sent:* Saturday, June 17, 2017 1:45 PM
> *To:* Justin Richer <[email-masked]>; Marius Scurtescu <
> [email-masked]>
> *Cc:* Richard Backman, Annabelle <[email-masked]>; Mike Jones <
> [email-masked]>; Henk Birkholz <[email-masked].
> de>; ID Events Mailing List <[email-masked]>; Phil Hunt <
> [email-masked]>
>
> Also, Mike you are missing the other requirement, for RPs to send events
> to an IdP. The iss+sub pair at the top level is broken in this case.
>
>
> Marius
>
>
>
>             <tel:(650)%20214-2410 <%28650%29%20214-2410>>
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 19 Jun 2017 12:11:26 -0700

[Editor Hat]
Just a side note. It would be good to get a resolution on this sometime this week. Based on the consensus reached, I would like to update the SET document next week in order to meet the publication timelines for Prague.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Jun 19, 2017, at 11:57 AM, Marius Scurtescu <[email-masked]> wrote:
> 
> On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
> I disagree that specific rules should be made for the “sub” claim.  Claims usage needs to be up to the application.  I know that many others agree with me, because the OpenID Connect working group designed the logout token inhttp://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0-2D04.html-23LogoutToken&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=F4o5yq8KJK6TchrRbj43SITOywEvWvZ-FKc1IbHpuV8&s=RXcr1ezsCvls3BIH27OWoxQwcpuL2dQnk3hIansGFQI&e=> (which is also used as an example in https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D01-23section-2D2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=F4o5yq8KJK6TchrRbj43SITOywEvWvZ-FKc1IbHpuV8&s=EiKIBUchCA7-J3brQaI5Y_tNOwPHw3OcL6chYjWEzzY&e=>) to use the “sub” claim in the normal way.  Prohibiting this usage would be a completely unnecessary breaking change – as it’s impossible to confuse a logout token with an ID Token, for reasons already cites in this thread.
> Solving the confusion is one problem. The other problem I keep mentioning is SETs issued by an RP to be sent to an IdP. How are we solving that problem Mike? In this case the top level iss is different from the iss of the sub, a top level sub is not possible.
> 
> And I don't want to downplay the confusion problem either. I think it is a real concern and I think a solid solution is important.
> 
> The OpenID Working Group designed logout tokens without secevent in mind. I agree we should not recklessly break compatibility, but to me it seems necessary in this case.
>  
>  
> 
> (I agree with the “iss” rules already in place at https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D01-23section-2D2.1&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=F4o5yq8KJK6TchrRbj43SITOywEvWvZ-FKc1IbHpuV8&s=ggQoMZ_yyFlCRsKPr9WGirxEZ3-vegx_E-fNpEG2OGw&e=>.  No further “iss” rules are needed.)
> 
> Further iss ruies are absolutely needed for the RP to IdP case described above.
> 
>  
>  
> 
> If typ can be use and no other claim is needed, then let's talk about that. I do think SET should mandate it. I don't understand why not. Can you please propose with examples how can typ be used?
> 
>  
>  
> 
> For SETs I cannot see how the nonce value is useful. That value is not passed back and it cannot be verified. Only the presence of the claim could have some use, hinting at the usage of the JWT, a very weak solution to the confusion problem.
>  
>  
> 
> If we define that sub must be at the event level then it is at a standard location, I don't see what the issue is. The impediment you mention is the actual solution. I don't think that a JWT library that was written for Id Tokens should be used to parse SETs. The library has to be SET aware, in which case the event level iss+sub is not an issue at all.
> 
> 
>  
> 
>   <>
> From: Yaron Sheffer [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Justin Richer <[email-masked] <mailto:[email-masked]>>; Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
> Cc: Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>; Mike Jones <[email-masked] <mailto:[email-masked]>>; Henk Birkholz <[email-masked] <mailto:[email-masked]>>; ID Events Mailing List <[email-masked] <mailto:[email-masked]>>; Phil Hunt <[email-masked] <mailto:[email-masked]>>
> 
> 
> On Jun 15, 2017, at 1:09 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
> 
>  
> 
>             <tel:(650)%20214-2410 <tel:%28650%29%20214-2410>>
> 
> 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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=F4o5yq8KJK6TchrRbj43SITOywEvWvZ-FKc1IbHpuV8&s=xyQQ7D6EchoHthYPpTNHzy4vYat2_FkHJ0tBj1ldLRI&e=>
>  
> 
> 
> 
> 
> 
> 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=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=F4o5yq8KJK6TchrRbj43SITOywEvWvZ-FKc1IbHpuV8&s=xyQQ7D6EchoHthYPpTNHzy4vYat2_FkHJ0tBj1ldLRI&e=>
>  
> 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=F4o5yq8KJK6TchrRbj43SITOywEvWvZ-FKc1IbHpuV8&s=xyQQ7D6EchoHthYPpTNHzy4vYat2_FkHJ0tBj1ldLRI&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=F4o5yq8KJK6TchrRbj43SITOywEvWvZ-FKc1IbHpuV8&s=xyQQ7D6EchoHthYPpTNHzy4vYat2_FkHJ0tBj1ldLRI&e=>

---

From: Mike Jones <[email-masked]>
Date: Mon, 19 Jun 2017 21:27:10 +0000

Marius, there’s nothing stopping you (or the RISC working group or other profiles) from defining events that can be sent from RPs to IdPs now, without any changes to the SET spec.  Specify the claims you want to use, and you’re golden.

But it would be counterproductive to require all other SETs to meet the requirements of your specific profile.  There are simpler use cases that can use claims in simpler ways.  Trying to make the simple use cases be complex will have the side effect of limiting the adoption of the spec, which wouldn’t be good for anyone.

If successful, SETs will have many different profiles.  That’s a sign of success – not a sign of weakness.

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; Justin Richer <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; Henk Birkholz <[email-masked]>; ID Events Mailing List <[email-masked]>; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I’m sorry to be slow replying to some messages in this thread.  I have a lot of other things on my plate, but I will take the time now to reply, because I wholeheartedly disagree with some of the statements below and believe it would be severely harmful to the specification and its adoption to act upon them.  Specifically:

  *

  *

  *

  *

                                                       -- Mike

From: Yaron Sheffer [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, June 17, 2017 1:45 PM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>; Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Cc: Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>

Did I miss anything?

Thanks,

    Yaron

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

Id-event mailing list

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Mon, 19 Jun 2017 14:43:18 -0700

Mike

Cc: openid connect list 

[personal hat]
I believe that your position severely limits the value of having a SET spec. 

If logout has different parsing rules than the other specs, interop is compromised due to different handling for different security components. 

As I said before, within the context of OpenId, I feel backchannel logout is too narrowly defined and many other logout and session events will be needed that are user triggered depending on scenario. 

Marius's point is important. 

For example we want to let the IDP know a subject has logged out of a specific RP. This is different from a logout command which signals single-logout / SLO at the OP to all RPs.  In this case the SET is issued by the RP and not the OP/IDP. 

Phil

> On Jun 19, 2017, at 2:27 PM, Mike Jones <[email-masked]> wrote:
> 
> On Sat, Jun 17, 2017 at 2:06 PM, Mike Jones <[email-masked]> wrote:

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Mon, 19 Jun 2017 21:49:57 +0000

If profiles assign further semantics or restrictions to the sub claim, then there will inevitably be conflicts between profiles (e.g. profile A says sub is an IPv4 address but profile B says it’s an IPv6 address, or profile A says it’s global but profile B says it’s scoped to the issuer). If these profiles want their events to be able to coexist in the same token as other profiles’ events, they will have to include some way to specify the subject within the event object as well.

If we think that all or the vast majority of profiles will meet the above criteria, then it is worth codifying this mechanism at the SET level so profiles don’t have to keep reinventing the wheel.

From: Mike Jones <[email-masked]>
Date: Monday, June 19, 2017 at 2:27 PM
To: Marius Scurtescu <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, Justin Richer <[email-masked]>, "Richard Backman, Annabelle" <[email-masked]>, Henk Birkholz <[email-masked]>, ID Events Mailing List <[email-masked]>, Phil Hunt <[email-masked]>
Subject: RE: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

                                                       -- Mike

  *

  *

  *

  *

                                                       -- Mike

Did I miss anything?

Thanks,

    Yaron

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

Id-event mailing list

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 19 Jun 2017 14:55:06 -0700

Mike, are you suggesting we define SETs in such a way that they will not
work for RISC? A top level iss+sub is clearly not working for RISC, and may
not work for logout either if you allow logout to be initiated from an RP.

Marius

On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones <[email-masked]>
wrote:

> Marius, there’s nothing stopping you (or the RISC working group or other
> profiles) from defining events that can be sent from RPs to IdPs now,
> without any changes to the SET spec.  Specify the claims you want to use,
> and you’re golden.
>
>
>
> But it would be counterproductive to require all other SETs to meet the
> requirements of your specific profile.  There are simpler use cases that
> can use claims in simpler ways.  Trying to make the simple use cases be
> complex will have the side effect of limiting the adoption of the spec,
> which wouldn’t be good for anyone.
>
>
>
> *From:* Marius Scurtescu [mailto:[email-masked]]
> *Sent:* Monday, June 19, 2017 11:58 AM
> *To:* Mike Jones <[email-masked]>
> *Cc:* Yaron Sheffer <[email-masked]>; Justin Richer <
> [email-masked]>; Richard Backman, Annabelle <[email-masked]>; Henk
> Birkholz <[email-masked]>; ID Events Mailing List <
> [email-masked]>; Phil Hunt <[email-masked]>
>
> The OpenID Working Group designed logout tokens without secevent in mind.
> I agree we should not recklessly break compatibility, but to me it seems
> necessary in this case.
>
>
>
>
>    -
>
>
>

---

From: "M.Lizar@OCG" <[email-masked]>
Date: Wed, 21 Jun 2017 13:46:42 -0500

FWIW - I agree with Mike that putting restrictions on the "sub" claim usage would unnecessarily complicate SETs for some use cases.

Its a lot easier to add to a spec and very difficult (if not impossible) to retract. In this regard, keeping it simple is critical for broad adoption. 

Mark

> On 19 Jun 2017, at 16:55, Marius Scurtescu <[email-masked]> wrote:
> 
> Mike, are you suggesting we define SETs in such a way that they will not work for RISC? A top level iss+sub is clearly not working for RISC, and may not work for logout either if you allow logout to be initiated from an RP.
> 
> Marius
> 
> On Mon, Jun 19, 2017 at 2:27 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: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; Justin Richer <[email-masked] <mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>>; Henk Birkholz <[email-masked] <mailto:[email-masked]>>; ID Events Mailing List <[email-masked] <mailto:[email-masked]>>; Phil Hunt <[email-masked] <mailto:[email-masked]>>
> 
> 
> I disagree that specific rules should be made for the “sub” claim.  Claims usage needs to be up to the application.  I know that many others agree with me, because the OpenID Connect working group designed the logout token in http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken <http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken> (which is also used as an example inhttps://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2 <https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2>) to use the “sub” claim in the normal way.  Prohibiting this usage would be a completely unnecessary breaking change – as it’s impossible to confuse a logout token with an ID Token, for reasons already cites in this thread.
> (I agree with the “iss” rules already in place at https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1 <https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1>.  No further “iss” rules are needed.)
>  
> 
> Mandatory solutions are being proposed in this thread to problems that there’s no evidence that we actually even have.  It’s already been established that it’s impossible for a SET to be confused for an ID Token – seehttps://www.ietf.org/mail-archive/web/id-event/current/msg00428.html <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_id-2Devent_current_msg00428.html&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_3zRoai115c&s=eKLTQPmYrV3ThfDbn90SCs55UROTPin_lgc6Rdr5Xow&e=>.  If people have data showing that this is possible with specific kinds of Access Tokens or other real JWT deployments, please provide specifics, so that we can use that data to inform appropriate engineering choices on our part.
> 
>  
> 
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> 
> 
> 
> 
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> 
>  
> 
>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Jun 2017 11:53:08 -0700

On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG <[email-masked]>
wrote:

> FWIW - I agree with Mike that putting restrictions on the "sub" claim
> usage would unnecessarily complicate SETs for some use cases.
>

sub is defined as optional in JWT, so technically we are not adding any
restrictions. Do you have examples of use cases that cannot handle sub at
the event level?

> Its a lot easier to add to a spec and very difficult (if not impossible)
> to retract.
>

I agree. I don't think anything is retracted.

Again, see:
https://tools.ietf.org/html/rfc7519#section-4.1.2

Last sentence of 4.1.2 states "Use of this claim is OPTIONAL."

> In this regard, keeping it simple is critical for broad adoption.
>
> Mark
>
>>    token in http://openid.net/specs/openid-connect-backchannel-1_0-04.
>>    html#LogoutToken (which is also used as an example in
>> And I don't want to downplay the confusion problem either. I think it is
>> a real concern and I think a solid solution is important.
>>
>>
>>
>>    - I’ll also respond to Annabelle’s assertion that “No other profile
>>    of JWT can ever use the "nonce” claim.”  This reflects a
>> P.S.  Food for thought:  Prohibiting the use of “sub” (or any other
>> claim) or forcing it to be located in a non-standard location makes about
>> as much sense as arbitrarily saying that, for a particular profile, the
>> Latin word for subject “subiectum” must be used as the claim name instead
>> of “sub”.  Yes, it will completely differentiate this profile from others
>> not spelling the claim name this way, but it would certainly be an
>> impediment to the use of standard JWT libraries and to interoperability.
>>
>>
>>
>> [email-masked]>; Henk Birkholz <
>> [email-masked]>; ID Events Mailing List <
>> We know from experience that naming collisions and replay attacks are
>> both things that happen. What’s being proposed is a simple, defensive
>> measure against these risks. You brought up JWT libraries: a general
>> solution actually makes it easier to use common libraries for JWT parsing.
>> A “usage-aware” JWT library could handle disambiguation for any JWT
>> profile, whereas with the status quo each profile would require unique
>> logic.
>>
>>
>>
>> --
>>
>> jWwlNKe4C_lLIGk&m=Uslj7GU7JPKHshmQl7j746XCsDft-00Y_
>> 3zRoai115c&s=P7mZuGzssKFZYVITX9ugLD4EKb9uyg7oMU7TmGMSWWs&e=
>>
>>
>>

---

From: Mike Jones <[email-masked]>
Date: Wed, 21 Jun 2017 20:19:33 +0000

Marius, the question “Do you have examples of use cases that cannot handle sub at the event level?” is no more useful than the question “Do you have examples of use cases that cannot handle ‘sub’ spelled as the Latin word ‘subiectum’?”  Yes, applications could always work around the inconveniences introduced by arbitrary claim renaming or repositioning, but they shouldn’t have to.  It just adds complexity and will hinder adoption.

It seems to me that your motivation for always having “sub” in the event payload, rather than a normal claim, is that that’s how you think RISC events will be structured, and that you want *all* events to also use the RISC event structuring.  To my way of thinking, if you really believe that you should be asking the SET spec to be withdrawn from the IETF and only define RISC events in the RISC working group.  But in fact, requiring all events to follow the RISC conventions makes no more sense than requiring all JWTs to be ID Tokens.  That would have made JWTs useless for many use cases.  Proposing to limit claims usage in SETs would likewise make them inapplicable for many non-RISC use cases.

We have a potential success on our hands.  Let’s not screw it up by making it unnecessarily complicated.

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Wednesday, June 21, 2017 1:53 PM
To: M.Lizar@OCG <[email-masked]>
Cc: Mike Jones <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; Henk Birkholz <[email-masked]>; Justin Richer <[email-masked]>; Yaron Sheffer <[email-masked]>; ID Events Mailing List <[email-masked]>; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>> wrote:
FWIW - I agree with Mike that putting restrictions on the "sub" claim usage would unnecessarily complicate SETs for some use cases.

sub is defined as optional in JWT, so technically we are not adding any restrictions. Do you have examples of use cases that cannot handle sub at the event level?

Its a lot easier to add to a spec and very difficult (if not impossible) to retract.

Again, see:

Mark

On 19 Jun 2017, at 16:55, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:

Marius

On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Marius, there’s nothing stopping you (or the RISC working group or other profiles) from defining events that can be sent from RPs to IdPs now, without any changes to the SET spec.  Specify the claims you want to use, and you’re golden.

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, June 19, 2017 11:58 AM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Justin Richer <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>

  *

  *

  *

  *

                                                       -- Mike

Did I miss anything?

Thanks,

    Yaron

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

Id-event mailing list

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 21 Jun 2017 13:34:07 -0700

Mike

It also includes how i think scim and logout should be structures. 

How is consistency so that any party can issue complex?

If we stick with the currently narrow scoped backchannel logout draft we create a lot of complexity for everyone else. Namely that backchannel will require special handling. 

If risc issues logouts they will be different. 

Phil

> On Jun 21, 2017, at 1:19 PM, Mike Jones <[email-masked]> wrote:
> 
> On Wed, Jun 21, 2017 at 11:46 AM, M.Lizar@OCG <[email-masked]> wrote:
> On Mon, Jun 19, 2017 at 2:27 PM, Mike Jones <[email-masked]> wrote:

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 21 Jun 2017 20:37:54 +0000

Inferring the message type by the presence of a parameter is a bad
practice. We should use "typ" header parameter to express it explicitly,
e.g., "typ":"sevent+jwt" which is an abbreviation of
"application/sevent+jwt". We should not put restrictions on "sub" or any
other claims.

On Thu, Jun 22, 2017 at 5:34 AM Phil Hunt (IDM) <[email-masked]>
wrote:

> If we stick with the currently narrow scoped backchannel logout draft we
> create a lot of complexity for everyone else. Namely that backchannel will
> require special handling.
>
> Marius, the question “Do you have examples of use cases that cannot
> handle sub at the event level?” is no more useful than the question “Do
> you have examples of use cases that cannot handle ‘sub’ spelled as the
> Latin word ‘subiectum’?”  Yes, applications could always work around the
> inconveniences introduced by arbitrary claim renaming or repositioning, but
> they shouldn’t have to.  It just adds complexity and will hinder adoption.
>
>
>
> It seems to me that your motivation for always having “sub” in the event
> payload, rather than a normal claim, is that that’s how you think RISC
> events will be structured, and that you want **all** events to also use
> the RISC event structuring.  To my way of thinking, if you really believe
> that you should be asking the SET spec to be withdrawn from the IETF and
> only define RISC events in the RISC working group.  But in fact, requiring
> all events to follow the RISC conventions makes no more sense than
> requiring all JWTs to be ID Tokens.  That would have made JWTs useless for
> many use cases.  Proposing to limit claims usage in SETs would likewise
> make them inapplicable for many non-RISC use cases.
>
>
>
> *From:* Marius Scurtescu [mailto:[email-masked]
> <[email-masked]>]
>
> *Sent:* Wednesday, June 21, 2017 1:53 PM
> *To:* M.Lizar@OCG <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; Richard Backman,
> Annabelle <[email-masked]>; Henk Birkholz <
> [email-masked]>; Justin Richer <[email-masked]>; Yaron
> Sheffer <[email-masked]>; ID Events Mailing List <[email-masked]>;
> Phil Hunt <[email-masked]>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc7519-23section-2D4.1.2&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=bZvbjqZ8WvjieTDo0RDVO7lra4E39zntb2VoNzpbXEw&s=WAv_oD-AGnfjcT0NInPG9PZasQCX_Dw5V38zPQh54ZI&e=>
>
>
>
>    token in
>    http://openid.net/specs/openid-connect-backchannel-1_0-04.html#LogoutToken
>    <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0-2D04.html-23LogoutToken&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=bZvbjqZ8WvjieTDo0RDVO7lra4E39zntb2VoNzpbXEw&s=V4bNzT8chRJyN92Pg_XsPzUfrOOoyt5hVgu1TvOH10Y&e=>
>    (which is also used as an example in
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D01-23section-2D2&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=bZvbjqZ8WvjieTDo0RDVO7lra4E39zntb2VoNzpbXEw&s=q9BxR1zqadSVOU5cAWaQrdhR7PWHoaH7yXZ1ZXegvmo&e=>)
>    <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D01-23section-2D2.1&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=bZvbjqZ8WvjieTDo0RDVO7lra4E39zntb2VoNzpbXEw&s=ygqO_3Tdt1Ca6tQHnanwAfVQ5TCXIYjaNuZ0ujffjK4&e=>.
>    JWT can ever use the "nonce” claim.”  This reflects a misunderstanding.
>    It’s the **value** of the nonce that self-secures the JWT – not that
>    any “nonce” claim is present.  Any and all JWTs can simultaneously use
>    “nonce” without any risk of conflict, since the nonce value is a
>    cryptographically secure random number.
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=bZvbjqZ8WvjieTDo0RDVO7lra4E39zntb2VoNzpbXEw&s=9UokTYqV-86RKyE-t7os9NKKugLyEPazX22ZXERWg2k&e=>
>
>
>
>
>
> 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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=bZvbjqZ8WvjieTDo0RDVO7lra4E39zntb2VoNzpbXEw&s=9UokTYqV-86RKyE-t7os9NKKugLyEPazX22ZXERWg2k&e=>
>
>
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=bZvbjqZ8WvjieTDo0RDVO7lra4E39zntb2VoNzpbXEw&s=9UokTYqV-86RKyE-t7os9NKKugLyEPazX22ZXERWg2k&e=>
>
>
>
>
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: John Bradley <[email-masked]>
Date: Wed, 21 Jun 2017 15:39:32 -0500

In the envelope typ is a media/mime type.  Registering application/idt+jwt if we register jwt as a structured name sufix.  

Using the cty is also possible.   I need to think about what is better but we can agree on a convention.

Not everything is going to be a set token like not every JWS is a JWT.

If we are going to define processing rules to stop collisions and confusion around JWT for different purposes, we should just start using the typ parameter based on the existing spec.

In general content sniffing if there is more than one option eventually gets you into trouble.

I am not convinced that forcing there to be no sub at the top level is a good idea.  

It is not the way we should differentiate between SET and id_tokens.

If sub is not allowed at the top level people will do non SET JWT for things where the subject is scoped to the iss of the token.

I think defining sub to be part of the event for cases where the sub is scoped differently from the issuer of the token is fine, but should not be required for all event types.

I think we should solve the confusion issue separately from the sub issue.

Sorry I am at CIS so trying to catch up on lists.

John B.

> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 21 Jun 2017 20:54:09 +0000

I agree with John that the JWT type confusion problem and the SET sub problem can and should be discussed separately. The secevents WG is probably not the right setting to discuss the former.

My concern with the sub claim is that two profiles may dictate conflicting semantics (e.g. Profile A says it’s a phone number, Profile B says it’s an email address). If these profiles don’t provide an alternate way to declare subject of their events, then they cannot be present within the same token. This incompatibility trap seems like something that could be easily missed by groups profiling SET.

From: John Bradley <[email-masked]>
Date: Wednesday, June 21, 2017 at 1:39 PM
To: Yaron Sheffer <[email-masked]>
Cc: Justin Richer <[email-masked]>, Marius Scurtescu <[email-masked]>, Annabelle Richard <[email-masked]>, Phil Hunt <[email-masked]>, Michael Jones <[email-masked]>, ID Events Mailing List <[email-masked]>, Henk Birkholz <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

John B.

On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

Id-event mailing list

---

From: John Bradley <[email-masked]>
Date: Wed, 21 Jun 2017 15:58:49 -0500

I thought we decided that we are only allowing set messages form the same family that agree on top level claims.

Otherwise there can be no top level claims and we are really defining a alternative format to JWT in some ways.

John B.

> On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>> On Jun 17, 2017, at 3:45 PM, Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
>>  
>>>>>>>> On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>>>>>> 
>>>>>>>>                 <[email-masked] <mailto:[email-masked]><mailto:[email-masked] <mailto:[email-masked]>>>:
>>>>>>>> 
>>>>>>>>                     +1
>>>>>>>> 
>>>>>>>>                     Phil
>>>>>>>> 
>>>>>>>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 21 Jun 2017 14:03:35 -0700

There are several problems that moving sub is w to. Note some of these may be somewhat conflicting but i wanted to get the out on the table...

1. Typing: Since there is no strong typing, moving sub from top level ensures the existing code should reject SETs. Yes we can also use the typing proposal in the header. The concern seems to be that existing implementations will ignore. 

2. Hard differentiator: Since sub's common usage is not globally unique, it often needs to be bound to an issuer for sub. The current draft works well if set issuer and sub issuer happen to be the same. But as far as I can tell reviewing the use cases this is only true for the current logout spec.

3. Consistency for Events: Having varying rules per spec at the top level means lack of interop. Many implementers expect to process provisioning, risk, and session management events through the same systems. To get around this deployers would have to deploy many more streams with specific logic generating potentially big pile of spaghetti architecture. 

4. Common usage practice: Should sub be used for other purposes?  Eg a security event about an ipaddress? Is it better to encourage profilers to avoid re-using sub at the top level and use a domain specific claim like ipaddresss?  Do we profile any use of sub at the top level to be globally unique and self defining?
Eg. "Sub":"urn:ietf:params:set:ipaddress:1.2.3.4"

Did I miss any?

Phil

> On Jun 21, 2017, at 1:39 PM, John Bradley <[email-masked]> wrote:
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 21 Jun 2017 14:12:55 -0700

Separate or combined may be evolving. Mike wants to keep the current backchannel logout very narrowly scoped. He suggested risc define its own duplicate definitions and meanings. 

That leads me to believe we will have multi-type events in practice.

Session cancellation can occur for many reasons. One of the differentiators we had tried to make was an assumption that user initiated events would be part of connect. Risk would cover variations that drive off of risk calculations like password reset. 

There are also signout events at rp's to let the OP know. These are not commands but notification that a resource session is cancelled. IOW single sign out not expected. 

Phil

> On Jun 21, 2017, at 1:58 PM, John Bradley <[email-masked]> wrote:
> 
>>>>>>>>>                 <[email-masked]<mailto:[email-masked]>>:
>>>>>>>>> 
>>>>>>>>>                     +1
>>>>>>>>> 
>>>>>>>>>                     Phil
>>>>>>>>> 
>>>>>>>>>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Jun 2017 14:19:36 -0700

On Wed, Jun 21, 2017 at 1:19 PM, Mike Jones <[email-masked]>
wrote:

> Latin word ‘subiectum’?”

I disagree. If sub at the event level is an issue then let's be concrete
about it.

>   Yes, applications could always work around the inconveniences introduced
> by arbitrary claim renaming or repositioning,
>

This is not an arbitrary repositioning, the reasons a very clear.

but they shouldn’t have to.  It just adds complexity and will hinder
> adoption.

Minor complexity added, if at all. The only downside is the slightly larger
size of SETs.

> the RISC event structuring.
>

This has absolutely nothing to do with RISC in particular. Both the
confusion problem and the RP issued SETs are generic SET problems that need
to be solved.

BTW, you never offered a solution to the RP issued SETs problem MIke. Can
you please do that?

>   To my way of thinking, if you really believe that you should be asking
> the SET spec to be withdrawn from the IETF and only define RISC events in
> the RISC working group.  But in fact, requiring all events to follow the
> RISC conventions makes no more sense than requiring all JWTs to be ID
> Tokens.  That would have made JWTs useless for many use cases.  Proposing
> to limit claims usage in SETs would likewise make them inapplicable for
> many non-RISC use cases.
>
>
>

Sure, let's solve all open issues first.

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Jun 2017 14:35:30 -0700

On Wed, Jun 21, 2017 at 1:39 PM, John Bradley <[email-masked]> wrote:

> In the envelope typ is a media/mime type.  Registering application/idt+jwt
> if we register jwt as a structured name sufix.
>
> If we are going to define processing rules to stop collisions and
> confusion around JWT for different purposes, we should just start using the
> typ parameter based on the existing spec.
>
> If sub is not allowed at the top level people will do non SET JWT for
> things where the subject is scoped to the iss of the token.
>
> I think defining sub to be part of the event for cases where the sub is
> scoped differently from the issuer of the token is fine, but should not be
> required for all event types.
>

Allowing sub at the event level as optional sounds good to me. If sub is
present at the event level then it probably should not be at the top level.

But, this optional approach makes the spec more complicated if anything.
Same for SET libraries.

While not necessarily a problem, iss+sub at the event level has another
nice property. It allows transmitters to use different signing keys (and
iss) for SETs, in some deployments this could be critical.

> I think we should solve the confusion issue separately from the sub issue.

Sure, they don't have to have the same solution.

>> <%2B1%20650-214-2410>
> Id-event mailing [email-masked]://www.ietf.org/mailman/listinfo/id-event
>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 21 Jun 2017 21:54:57 +0000

The spec says that the events claim SHOULD NOT be used to express multiple logical events. If it’s also not used to express events from different profiles that correspond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypothetical RISC logout event), then I’m not sure what use case that leaves for multiple events in one SET.

From: Id-event <[email-masked]> on behalf of "Phil Hunt (IDM)" <[email-masked]>
Date: Wednesday, June 21, 2017 at 2:12 PM
To: John Bradley <[email-masked]>
Cc: "Richard Backman, Annabelle" <[email-masked]>, Henk Birkholz <[email-masked]>, Justin Richer <[email-masked]>, Marius Scurtescu <[email-masked]>, Yaron Sheffer <[email-masked]>, Michael Jones <[email-masked]>, ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Phil

On Jun 21, 2017, at 1:58 PM, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
I thought we decided that we are only allowing set messages form the same family that agree on top level claims.

John B.

On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

From: John Bradley <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 21, 2017 at 1:39 PM
To: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>
Cc: Justin Richer <[email-masked]<mailto:[email-masked]>>, Marius Scurtescu <[email-masked]<mailto:[email-masked]>>, Annabelle Richard <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>, Michael Jones <[email-masked]<mailto:[email-masked]>>, ID Events Mailing List <[email-masked]<mailto:[email-masked]>>, Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

John B.

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

On Mon, Jun 12, 2017 at 3:15 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:

    Marius

                +1 especially for "type"

                2017-06-09 10:32 GMT+09:00 Phil Hunt (IDM)
                <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>:

                    +1

                    Phil

--

Id-event mailing list

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Jun 2017 14:58:55 -0700

Example for multiple events within same profile: IdP account is disabled
(because of hijacking), this can lead to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius

On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <
[email-masked]> wrote:

> The spec says that the events claim SHOULD NOT be used to express multiple
> logical events. If it’s also not used to express events from different
> profiles that correspond to the same logical event (e.g. an OIDC
> backchannel logout event alongside a hypothetical RISC logout event), then
> I’m not sure what use case that leaves for multiple events in one SET.
>
>
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of "Phil Hunt
> (IDM)" <[email-masked]>
> *Date: *Wednesday, June 21, 2017 at 2:12 PM
> *To: *John Bradley <[email-masked]>
> *Cc: *"Richard Backman, Annabelle" <[email-masked]>, Henk Birkholz <
> [email-masked]>, Justin Richer <[email-masked]>, Marius
> Scurtescu <[email-masked]>, Yaron Sheffer <[email-masked]>,
> Michael Jones <[email-masked]>, ID Events Mailing List <
> [email-masked]>
>
> Separate or combined may be evolving. Mike wants to keep the current
> backchannel logout very narrowly scoped. He suggested risc define its own
> duplicate definitions and meanings.
>
>
>
> Session cancellation can occur for many reasons. One of the
> differentiators we had tried to make was an assumption that user initiated
> events would be part of connect. Risk would cover variations that drive off
> of risk calculations like password reset.
>
>
>
> There are also signout events at rp's to let the OP know. These are not
> commands but notification that a resource session is cancelled. IOW single
> sign out not expected.
>
>
> Phil
>
>
> I agree with John that the JWT type confusion problem and the SET sub
> problem can and should be discussed separately. The secevents WG is
> probably not the right setting to discuss the former.
>
>
>
> My concern with the sub claim is that two profiles may dictate conflicting
> semantics (e.g. Profile A says it’s a phone number, Profile B says it’s an
> email address). If these profiles don’t provide an alternate way to declare
> subject of their events, then they cannot be present within the same token.
> This incompatibility trap seems like something that could be easily missed
> by groups profiling SET.
>
>
>
> --
>
> *From: *John Bradley <[email-masked]>
> *Date: *Wednesday, June 21, 2017 at 1:39 PM
> *To: *Yaron Sheffer <[email-masked]>
> *Cc: *Justin Richer <[email-masked]>, Marius Scurtescu <
> [email-masked]>, Annabelle Richard <[email-masked]>, Phil
> Hunt <[email-masked]>, Michael Jones <[email-masked]>,
> ID Events Mailing List <[email-masked]>, Henk Birkholz <
>                     https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=

---

From: Mike Jones <[email-masked]>
Date: Wed, 21 Jun 2017 22:03:38 +0000

Marius, you wrote “BTW, you never offered a solution to the RP issued SETs problem MIke. Can you please do that?”  I thought we already had a well-understood solution to that, but I’ll repeat it here.  I’ll give the example assuming that the event is about an OpenID Connect account that is named by an (“iss”, “sub”) pair.

If the RP is issuing the SET, it already must identify itself using the top-level “iss” claim, per the SET spec.  The OpenID Connect account that is the subject of the event would contain the (“iss”, “sub”) values in the event payload.  In fact, I’m assuming that that would be the case for all RISC events (and possibly for some other event profiles too).  I’m completely supportive of that choice if made by a profile.

But there will also be use cases – possibly non-identity use cases, in which the thing being operated on doesn’t have any issuer value or in which the event issuer is always the same as the issuer for the thing being operated on.  Trying to impose the choices made by one SET profile onto all others, though, assumes we know way more about their use cases than we actually do.  We need to leave their conventions up to them – just like JWT left claims conventions up to profiles.  That’s why it’s general-purpose and being widely used.

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Wednesday, June 21, 2017 4:20 PM
To: Mike Jones <[email-masked]>
Cc: M.Lizar@OCG <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; Henk Birkholz <[email-masked]>; Justin Richer <[email-masked]>; Yaron Sheffer <[email-masked]>; ID Events Mailing List <[email-masked]>; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

On Wed, Jun 21, 2017 at 1:19 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Marius, the question “Do you have examples of use cases that cannot handle sub at the event level?” is no more useful than the question “Do you have examples of use cases that cannot handle ‘sub’ spelled as the Latin word ‘subiectum’?”

I disagree. If sub at the event level is an issue then let's be concrete about it.

  Yes, applications could always work around the inconveniences introduced by arbitrary claim renaming or repositioning,

but they shouldn’t have to.  It just adds complexity and will hinder adoption.

Minor complexity added, if at all. The only downside is the slightly larger size of SETs.

It seems to me that your motivation for always having “sub” in the event payload, rather than a normal claim, is that that’s how you think RISC events will be structured, and that you want *all* events to also use the RISC event structuring.

This has absolutely nothing to do with RISC in particular. Both the confusion problem and the RP issued SETs are generic SET problems that need to be solved.

BTW, you never offered a solution to the RP issued SETs problem MIke. Can you please do that?

  To my way of thinking, if you really believe that you should be asking the SET spec to be withdrawn from the IETF and only define RISC events in the RISC working group.  But in fact, requiring all events to follow the RISC conventions makes no more sense than requiring all JWTs to be ID Tokens.  That would have made JWTs useless for many use cases.  Proposing to limit claims usage in SETs would likewise make them inapplicable for many non-RISC use cases.

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, June 21, 2017 1:53 PM
To: M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>; Justin Richer <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>

Again, see:

Mark

Marius

                                                       -- Mike

  *

  *

  *

  *

                                                       -- Mike

Did I miss anything?

Thanks,

    Yaron

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

Id-event mailing list

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Jun 2017 15:32:11 -0700

On Wed, Jun 21, 2017 at 3:03 PM, Mike Jones <[email-masked]>
wrote:

> Marius, you wrote “BTW, you never offered a solution to the RP issued
> SETs problem MIke. Can you please do that?”  I thought we already had a
> well-understood solution to that, but I’ll repeat it here.  I’ll give the
> example assuming that the event is about an OpenID Connect account that is
> named by an (“iss”, “sub”) pair.
>
>
>
> If the RP is issuing the SET, it already must identify itself using the
> top-level “iss” claim, per the SET spec.  The OpenID Connect account that
> is the subject of the event would contain the (“iss”, “sub”) values in the
> event payload.  In fact, I’m assuming that that would be the case for all
> RISC events (and possibly for some other event profiles too).  I’m
> completely supportive of that choice if made by a profile.
>
>
>
> But there will also be use cases – possibly non-identity use cases, in
> which the thing being operated on doesn’t have any issuer value or in which
> the event issuer is always the same as the issuer for the thing being
> operated on.  Trying to impose the choices made by one SET profile onto all
> others, though, assumes we know way more about their use cases than we
> actually do.  We need to leave their conventions up to them – just like JWT
> left claims conventions up to profiles.  That’s why it’s general-purpose
> and being widely used.
>

Alright, so the solution is to optionally allow iss+sub at the event level
(in which case there is no sub at the top level)? Is this something
secevent defines or profiles would have to each define separately?

And again, I don't see the RP issued SET as a particular profile problem.

Also, speaking of general purpose solutions. To me sub at event level is
general purpose, guaranteed to not cause conflicts. sub at the top level on
the other hand will cause conflicts and force most (or all) oauth based
profiles to re-define how sub is used.

The only problem with sub only at event level that I am aware of is the
compatibly breakage for the logout profile. I agree that we should not take
breakages lightly.

> *Sent:* Wednesday, June 21, 2017 4:20 PM
> *Cc:* M.Lizar@OCG <[email-masked]>; Richard Backman,

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 21 Jun 2017 22:38:05 +0000

Fair point. If we do not intend to support multiple profiles within a single SET, then I’m less concerned about leaving sub semantics up to the profiles.

From: Marius Scurtescu <[email-masked]>
Date: Wednesday, June 21, 2017 at 2:58 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: "Phil Hunt (IDM)" <[email-masked]>, John Bradley <[email-masked]>, Henk Birkholz <[email-masked]>, Justin Richer <[email-masked]>, Yaron Sheffer <[email-masked]>, Michael Jones <[email-masked]>, ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Example for multiple events within same profile: IdP account is disabled (because of hijacking), this can lead to two events:
1. "account-disabled"
2. "sessions-revoked"

Marius

On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:
The spec says that the events claim SHOULD NOT be used to express multiple logical events. If it’s also not used to express events from different profiles that correspond to the same logical event (e.g. an OIDC backchannel logout event alongside a hypothetical RISC logout event), then I’m not sure what use case that leaves for multiple events in one SET.

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of "Phil Hunt (IDM)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 21, 2017 at 2:12 PM
To: John Bradley <[email-masked]<mailto:[email-masked]>>
Cc: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>, Henk Birkholz <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>, Marius Scurtescu <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Michael Jones <[email-masked]<mailto:[email-masked]>>, ID Events Mailing List <[email-masked]<mailto:[email-masked]>>

Phil

John B.

John B.

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

Id-event mailing list

---

From: Phil Hunt <[email-masked]>
Date: Wed, 21 Jun 2017 16:39:14 -0700

So I understand what is being proposed is:

If the event type uses “sub” to identify its subject, and the issuer of the subject is identical to the issuer for the event, then “sub” may be used at the top level. Otherwise, the subject of an event (e.g. “sub”) and any other claims required to uniquely identify the subject MUST be contained in the event payload.

For example, an ip address of 1.2.3.4 might be represented in a “ipaddress” claim defined in the event payload. “ipaddress”:”1.2.3.4"
A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 might be identified in the event payload as: “sub”:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4”

A Connect Logout event from an OP uses the top level sub claim and depends on “iss” being the same for the event issuer AND the subject. This means that no party may issue logout events on behalf of the OP.

Phil

> On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of "Phil Hunt (IDM)" <[email-masked] <mailto:[email-masked]>>
>> To: John Bradley <[email-masked] <mailto:[email-masked]>>
>> Cc: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>, Henk Birkholz <[email-masked] <mailto:[email-masked]>>, Justin Richer <[email-masked] <mailto:[email-masked]>>, Marius Scurtescu <[email-masked] <mailto:[email-masked]>>, Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, Michael Jones <[email-masked] <mailto:[email-masked]>>, ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
>> 
>> On Jun 21, 2017, at 1:58 PM, John Bradley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>> On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>>>  
>>>> From: John Bradley <[email-masked] <mailto:[email-masked]>>
>>>> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>
>>>> Cc: Justin Richer <[email-masked] <mailto:[email-masked]>>, Marius Scurtescu <[email-masked] <mailto:[email-masked]>>, Annabelle Richard <[email-masked] <mailto:[email-masked]>>, Phil Hunt <[email-masked] <mailto:[email-masked]>>, Michael Jones <[email-masked] <mailto:[email-masked]>>, ID Events Mailing List <[email-masked] <mailto:[email-masked]>>, Henk Birkholz <[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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>
>>>>>>  
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=> 
>>>>> 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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>
>>>>  
>>> 
>>>  
>>> 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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>
>

---

From: Mike Jones <[email-masked]>
Date: Wed, 21 Jun 2017 23:45:57 +0000

The proposal that I believe has the most support is keeping things as they are, leaving it up to profiles and applications to define which claims they use and how they use them.

It would be fine for some profiles to use the language below.

– Mike
From: Phil Hunt<mailto:[email-masked]>
Sent: Wednesday, June 21, 2017 6:39 PM
To: Richard Backman, Annabelle<mailto:[email-masked]>
Cc: Marius Scurtescu<mailto:[email-masked]>; John Bradley<mailto:[email-masked]>; Henk Birkholz<mailto:[email-masked]>; Justin Richer<mailto:[email-masked]>; Yaron Sheffer<mailto:[email-masked]>; Mike Jones<mailto:[email-masked]>; ID Events Mailing List<mailto:[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Phil

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

On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

From: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, June 21, 2017 at 2:58 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: "Phil Hunt (IDM)" <[email-masked]<mailto:[email-masked]>>, John Bradley <[email-masked]<mailto:[email-masked]>>, Henk Birkholz <[email-masked]<mailto:[email-masked]>>, Justin Richer <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Michael Jones <[email-masked]<mailto:[email-masked]>>, ID Events Mailing List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Marius

Phil

John B.

John B.

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

_______________________________________________
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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>

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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>

_______________________________________________
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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>

_______________________________________________
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=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 21 Jun 2017 17:16:21 -0700

On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones <[email-masked]>
wrote:

> The proposal that I believe has the most support is keeping things as they
> are, leaving it up to profiles and applications to define which claims they
> use and how they use them.
>
>
>

I don't think this is acceptable Mike.

I'll summarize again.

We have two open problem to solve:
1. SETs could be confused for other JWTs (Id Tokens and Access Tokens in
particular).
2. In some cases there is an "iss" conflict at the top level, the "sub"
related "iss" is different from the SET "iss". This is not specific to any
particular profile.

Further, problem 1 needs a short term solution and a long term solution.
The important solution for secevent is the short term one.

Out of the above only the long term solution for problem 1 has some
promising resolution (using typ or cty).

So, keeping things as they are nothing relevant to secevent is solved
basically.

Again, if your main concern is compatibility for the logout spec (which is
understandable) then let's talk about that and see if we can find a
solution for the two problems above with that constraint. Unfortunately I
cannot see such a solution.

>
>
> – Mike
>
> *From: *Phil Hunt <[email-masked]>
> *Sent: *Wednesday, June 21, 2017 6:39 PM
> *To: *Richard Backman, Annabelle <[email-masked]>
> *Cc: *Marius Scurtescu <[email-masked]>; John Bradley
> <[email-masked]>; Henk Birkholz <[email-masked]>; Justin
> Richer <[email-masked]>; Yaron Sheffer <[email-masked]>; Mike
> Jones <[email-masked]>; ID Events Mailing List
> <[email-masked]>
>
> If the event type uses “sub” to identify its subject, and the issuer of
> the subject is identical to the issuer for the event, then “sub” may be
> used at the top level. Otherwise, the subject of an event (e.g. “sub”) and
> any other claims required to uniquely identify the subject MUST be
> contained in the event payload.
>
> For example, an ip address of 1.2.3.4 might be represented in a
> “ipaddress” claim defined in the event payload. “ipaddress”:”1.2.3.4"
> A SCIM resource URI of https://scim.example.com/users/
> ac1faebbfd3c45ce9a242bd3859c82c4 might be identified in the event payload
> as: “sub”:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4
> ”
>
> A Connect Logout event from an OP uses the top level sub claim and depends
> on “iss” being the same for the event issuer AND the subject. This means
> that no party may issue logout events on behalf of the OP.
>
>
> Phil
>
> www.independentid.com
> [email-masked]
> Fair point. If we do not intend to support multiple profiles within a
> single SET, then I’m less concerned about leaving sub semantics up to the
> profiles.
>
> --
> *From: *Marius Scurtescu <[email-masked]>
> *Date: *Wednesday, June 21, 2017 at 2:58 PM
> *To: *"Richard Backman, Annabelle" <[email-masked]>
> *Cc: *"Phil Hunt (IDM)" <[email-masked]>, John Bradley <
> [email-masked]>, Henk Birkholz <[email-masked]>,
> Justin Richer <[email-masked]>, Yaron Sheffer <[email-masked]>,
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>
>
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>
>
>
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=l-O82NLI-b8QDl2Q9TkpVobQz3h_4TyBGAq5pfZsOcw&s=0LWRlGTIqiTsDhmHuRIB5-RRft82C729-PEYJhLu5SQ&e=>
>
>
>
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 21 Jun 2017 17:25:34 -0700

+1

Phil

> On Jun 21, 2017, at 5:16 PM, Marius Scurtescu <[email-masked]> wrote:
> 
>> On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones <[email-masked]> wrote:
> 1. SETs could be confused for other JWTs (Id Tokens and Access Tokens in particular).
> 2. In some cases there is an "iss" conflict at the top level, the "sub" related "iss" is different from the SET "iss". This is not specific to any particular profile.
> 
> Further, problem 1 needs a short term solution and a long term solution. The important solution for secevent is the short term one.
> 
> Out of the above only the long term solution for problem 1 has some promising resolution (using typ or cty).
> 
> So, keeping things as they are nothing relevant to secevent is solved basically.
> 
> Again, if your main concern is compatibility for the logout spec (which is understandable) then let's talk about that and see if we can find a solution for the two problems above with that constraint. Unfortunately I cannot see such a solution.
> 
> 
> 
>  
>>  
>> 
>> – Mike
>> 
>> From: Phil Hunt
>> To: Richard Backman, Annabelle
>> Cc: Marius Scurtescu; John Bradley; Henk Birkholz; Justin Richer; Yaron Sheffer; Mike Jones; ID Events Mailing List
>> 
>> 
>>>> On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle <[email-masked]> wrote:

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Jun 2017 14:58:02 -0500

A very abstract concern I would have is that if you have some entity
issuing SETs assuming one profile, how is it ensured that everything
consuming those SETs interpret it using the same profile?  I know there
are a lot of things deployed out there in the greater OAuth world that
use out-of-band agreements between participants, but maybe we want to
move away from that sort of thing.

-Ben

On 06/21/2017 07:25 PM, Phil Hunt (IDM) wrote:
> +1
>
> Phil
>
> On Jun 21, 2017, at 5:16 PM, Marius Scurtescu <[email-masked]
>> On Wed, Jun 21, 2017 at 4:45 PM, Mike Jones
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     The proposal that I believe has the most support is keeping
>>     things as they are, leaving it up to profiles and applications to
>>     define which claims they use and how they use them.
>>
>>      
>>
>> 2. In some cases there is an "iss" conflict at the top level, the
>> "sub" related "iss" is different from the SET "iss". This is not
>> specific to any particular profile.
>>
>> Further, problem 1 needs a short term solution and a long term
>> solution. The important solution for secevent is the short term one.
>>
>> Again, if your main concern is compatibility for the logout spec
>> (which is understandable) then let's talk about that and see if we
>> can find a solution for the two problems above with that constraint.
>> Unfortunately I cannot see such a solution.
>>
>>
>>
>>  
>>
>>      
>>
>>     – Mike
>>
>>     *From: *Phil Hunt <mailto:[email-masked]>
>>     *To: *Richard Backman, Annabelle <mailto:[email-masked]>
>>     *Cc: *Marius Scurtescu <mailto:[email-masked]>; John
>>     Bradley <mailto:[email-masked]>; Henk Birkholz
>>     <mailto:[email-masked]>; Justin Richer
>>     <mailto:[email-masked]>; Yaron Sheffer
>>     <mailto:[email-masked]>; Mike Jones
>>     <mailto:[email-masked]>; ID Events Mailing List
>>     <mailto:[email-masked]>
>>
>>
>>     If the event type uses “sub” to identify its subject, and the
>>     issuer of the subject is identical to the issuer for the event,
>>     then “sub” may be used at the top level. Otherwise, the subject
>>     of an event (e.g. “sub”) and any other claims required to
>>     uniquely identify the subject MUST be contained in the event payload.
>>
>>     A SCIM resource URI of
>>     https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__scim.example.com_users_ac1faebbfd3c45ce9a242bd3859c82c4&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=uqeXpbQbQPtc33ymleIRlveZPtHm9r9wqoWNP2zG0K4&s=97MbuduWH8BZWdttvVR0bSUjrtRvHpoKtfJ_1u6MiU4&e=>
>>     might be identified in the event payload as:
>>     “sub”:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__scim.example.com_users_ac1faebbfd3c45ce9a242bd3859c82c4&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=uqeXpbQbQPtc33ymleIRlveZPtHm9r9wqoWNP2zG0K4&s=97MbuduWH8BZWdttvVR0bSUjrtRvHpoKtfJ_1u6MiU4&e=>”
>>
>>     A Connect Logout event from an OP uses the top level sub claim
>>     and depends on “iss” being the same for the event issuer AND the
>>     subject. This means that no party may issue logout events on
>>     behalf of the OP.
>>
>>
>>     Phil
>>
>>     <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=IPOgg6e8SsqiBFnOCsQrY6Oh1ppDIQl_YMP2jcBlR0w&s=2Z6KTHoFGGCV0Rp37kqovm2jeptanbYHiZpx0SvIo-8&e=>
>>     [email-masked] <mailto:[email-masked]>
>>
>>>     On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle
>>>     Fair point. If we do not intend to support multiple profiles
>>>     within a single SET, then I’m less concerned about leaving sub
>>>     semantics up to the profiles.
>>>      
>>>     -- 
>>>     *From: *Marius Scurtescu <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *To: *"Richard Backman, Annabelle" <[email-masked]
>>>     <mailto:[email-masked]>>
>>>     *Cc: *"Phil Hunt (IDM)" <[email-masked]
>>>     <mailto:[email-masked]>>, John Bradley <[email-masked]
>>>     <mailto:[email-masked]>>, Henk Birkholz
>>>     <mailto:[email-masked]>>, Justin Richer
>>>     <[email-masked] <mailto:[email-masked]>>, Yaron Sheffer
>>>     <[email-masked] <mailto:[email-masked]>>, Michael
>>>     Jones <[email-masked]
>>>     <mailto:[email-masked]>>, ID Events Mailing List
>>>     <[email-masked] <mailto:[email-masked]>>
>>>     Example for multiple events within same profile: IdP account is
>>>     disabled (because of hijacking), this can lead to two events:
>>>     1. "account-disabled"
>>>     2. "sessions-revoked"
>>>
>>>     Marius
>>>      
>>>     On Wed, Jun 21, 2017 at 2:54 PM, Richard Backman, Annabelle
>>>>     The spec says that the events claim SHOULD NOT be used to
>>>>     express multiple logical events. If it’s also not used to
>>>>     express events from different profiles that correspond to the
>>>>     same logical event (e.g. an OIDC backchannel logout event
>>>>     alongside a hypothetical RISC logout event), then I’m not sure
>>>>     what use case that leaves for multiple events in one SET.
>>>>      
>>>>     -- 
>>>>     <mailto:[email-masked]>> on behalf of "Phil Hunt
>>>>     (IDM)" <[email-masked] <mailto:[email-masked]>>
>>>>     *To: *John Bradley <[email-masked] <mailto:[email-masked]>>
>>>>     <mailto:[email-masked]>>, Henk Birkholz
>>>>     <mailto:[email-masked]>>, Justin Richer
>>>>     <[email-masked] <mailto:[email-masked]>>, Marius Scurtescu
>>>>     <[email-masked] <mailto:[email-masked]>>, Yaron
>>>>     Sheffer <[email-masked] <mailto:[email-masked]>>,
>>>>     Michael Jones <[email-masked]
>>>>     <mailto:[email-masked]>>, ID Events Mailing List
>>>>     <[email-masked] <mailto:[email-masked]>>
>>>>
>>>>     Separate or combined may be evolving. Mike wants to keep the
>>>>     current backchannel logout very narrowly scoped. He suggested
>>>>     risc define its own duplicate definitions and meanings. 
>>>>      
>>>>     differentiators we had tried to make was an assumption that
>>>>     user initiated events would be part of connect. Risk would
>>>>     cover variations that drive off of risk calculations like
>>>>     password reset. 
>>>>      
>>>>     There are also signout events at rp's to let the OP know. These
>>>>     are not commands but notification that a resource session is
>>>>     cancelled. IOW single sign out not expected. 
>>>>
>>>>     Phil
>>>>
>>>>
>>>>>     I thought we decided that we are only allowing set messages
>>>>>     form the same family that agree on top level claims.
>>>>>      
>>>>>     Otherwise there can be no top level claims and we are really
>>>>>     defining a alternative format to JWT in some ways.
>>>>>      
>>>>>     John B.
>>>>>      
>>>>>>     On Jun 21, 2017, at 3:54 PM, Richard Backman, Annabelle
>>>>>>     I agree with John that the JWT type confusion problem and the
>>>>>>     SET sub problem can and should be discussed separately. The
>>>>>>     secevents WG is probably not the right setting to discuss the
>>>>>>     former.
>>>>>>      
>>>>>>     My concern with the sub claim is that two profiles may
>>>>>>     dictate conflicting semantics (e.g. Profile A says it’s a
>>>>>>     phone number, Profile B says it’s an email address). If these
>>>>>>     profiles don’t provide an alternate way to declare subject of
>>>>>>     their events, then they cannot be present within the same
>>>>>>     token. This incompatibility trap seems like something that
>>>>>>     could be easily missed by groups profiling SET.
>>>>>>      
>>>>>>     -- 
>>>>>>     *From: *John Bradley <[email-masked]
>>>>>>     <mailto:[email-masked]>>
>>>>>>     *To: *Yaron Sheffer <[email-masked]
>>>>>>     <mailto:[email-masked]>>
>>>>>>     *Cc: *Justin Richer <[email-masked]
>>>>>>     <mailto:[email-masked]>>, Marius Scurtescu
>>>>>>     <[email-masked] <mailto:[email-masked]>>,
>>>>>>     Annabelle Richard <[email-masked]
>>>>>>     <mailto:[email-masked]>>, Phil Hunt
>>>>>>     <[email-masked] <mailto:[email-masked]>>, Michael
>>>>>>     Jones <[email-masked]
>>>>>>     <mailto:[email-masked]>>, ID Events Mailing List
>>>>>>     In the envelope typ is a media/mime type.  Registering
>>>>>>     application/idt+jwt if we register jwt as a structured name
>>>>>>     sufix.  
>>>>>>      
>>>>>>     Using the cty is also possible.   I need to think about what
>>>>>>     is better but we can agree on a convention.
>>>>>>      
>>>>>>     If we are going to define processing rules to stop collisions
>>>>>>     and confusion around JWT for different purposes, we should
>>>>>>     just start using the typ parameter based on the existing spec.
>>>>>>      
>>>>>>     If sub is not allowed at the top level people will do non SET
>>>>>>     JWT for things where the subject is scoped to the iss of the
>>>>>>     token.
>>>>>>      
>>>>>>     I think defining sub to be part of the event for cases where
>>>>>>     the sub is scoped differently from the issuer of the token is
>>>>>>     fine, but should not be required for all event types.
>>>>>>      
>>>>>>>     On Jun 17, 2017, at 3:45 PM, Yaron Sheffer
>>>>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>      
>>>>>>>     Everybody agrees with Marius's short-term solution, specific
>>>>>>>     rules for "sub" and "iss" that can be defined in the SET spec.
>>>>>>>     Almost everybody agrees on a long-term "usage" claim ("type"
>>>>>>>     is taken) that should be defined elsewhere, e.g. in the JWT BCP.
>>>>>>>     Did I miss anything?
>>>>>>>     By the way, if we do add a "usage" claim, we need to also
>>>>>>>     use it in the SET document before it is published.
>>>>>>>     Thanks,
>>>>>>>         Yaron
>>>>>>>      
>>>>>>>>>     On Jun 15, 2017, at 1:09 PM, Marius Scurtescu
>>>>>>>>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>>>      
>>>>>>>>>     Also, Mike you are missing the other requirement, for RPs
>>>>>>>>>     to send events to an IdP. The iss+sub pair at the top
>>>>>>>>>     level is broken in this case.
>>>>>>>>>
>>>>>>>>>     Marius
>>>>>>>>>      
>>>>>>>>>>>     Your explanation for why this is a non-problem is
>>>>>>>>>>>     dependent upon side effects of elements of OpenID
>>>>>>>>>>>     Connect that were not designed to solve this issue. As a
>>>>>>>>>>>     result, I see several issues with it:
>>>>>>>>>>>
>>>>>>>>>>>     1.       The caller of the Token Endpoint is the only
>>>>>>>>>>>     party that can be certain that a nonce-less ID Token is
>>>>>>>>>>>     really an ID Token. Any party that the caller passes the
>>>>>>>>>>>     ID Token off to has no way to verify its provenance.
>>>>>>>>>>>
>>>>>>>>>>>     4.      This is only a solution for ID Tokens. Every
>>>>>>>>>>>     other JWT profile that cares about disambiguation has to
>>>>>>>>>>>     invent its own solution to the problem.
>>>>>>>>>>>
>>>>>>>>>>>      
>>>>>>>>>>>     We know from experience that naming collisions and
>>>>>>>>>>>     replay attacks are both things that happen. What’s being
>>>>>>>>>>>     proposed is a simple, defensive measure against these
>>>>>>>>>>>     risks. You brought up JWT libraries: a general solution
>>>>>>>>>>>     actually makes it easier to use common libraries for JWT
>>>>>>>>>>>     parsing. A “usage-aware” JWT library could handle
>>>>>>>>>>>     disambiguation for any JWT profile, whereas with the
>>>>>>>>>>>     status quo each profile would require unique logic.
>>>>>>>>>>>      
>>>>>>>>>>>     -- 
>>>>>>>>>>>     <mailto:[email-masked]>> on behalf of Mike
>>>>>>>>>>>     Jones <[email-masked]
>>>>>>>>>>>     <mailto:[email-masked]>>
>>>>>>>>>>>     <[email-masked] <mailto:[email-masked]>>, Henk
>>>>>>>>>>>     Birkholz <[email-masked]
>>>>>>>>>>>     You’ve heard of “premature optimization”.  I’d
>>>>>>>>>>>     characterize the proposals in this thread as “premature
>>>>>>>>>>>     pessimation” – making things that can and should be
>>>>>>>>>>>     simple complex, without data showing there’s any need to
>>>>>>>>>>>     do so.
>>>>>>>>>>>      
>>>>>>>>>>>     problems that there’s no evidence that we actually even
>>>>>>>>>>>     have.  It’s already been established that it’s
>>>>>>>>>>>     impossible for a SET to be confused for an ID Token –
>>>>>>>>>>>     If people have data showing that this is possible with
>>>>>>>>>>>     specific kinds of Access Tokens or other real JWT
>>>>>>>>>>>     deployments, please provide specifics, so that we can
>>>>>>>>>>>     use that data to inform appropriate engineering choices
>>>>>>>>>>>     on our part.
>>>>>>>>>>>      
>>>>>>>>>>>     The proposed “solutions”, such as prohibiting the use of
>>>>>>>>>>>     “sub” in the normal way, or requiring a type claim,
>>>>>>>>>>>     would make previously simple things unnecessarily
>>>>>>>>>>>     complex.  Yes, then the result is then different than a
>>>>>>>>>>>     normal JWT but a consequence of this is that custom
>>>>>>>>>>>     parsing code would have to be used, rather than a
>>>>>>>>>>>     standard JWT parser.  The more unwieldy we make it to
>>>>>>>>>>>     use SETs, the more likely developers are to just create
>>>>>>>>>>>     their own data structures.  Keeping it simple is the key
>>>>>>>>>>>     to adoption.  Standards are only useful if they are
>>>>>>>>>>>     actually used.
>>>>>>>>>>>      
>>>>>>>>>>>                                                     -- Mike
>>>>>>>>>>>      
>>>>>>>>>>>     <mailto:[email-masked]>] *On Behalf
>>>>>>>>>>>     Of *Richard Backman, Annabelle
>>>>>>>>>>>     *Subject:* Re: [Id-event] solution for Id/Access Token
>>>>>>>>>>>     confusion and distinct SET issuer
>>>>>>>>>>>      
>>>>>>>>>>>     To your first question, I think a better analogy would
>>>>>>>>>>>     be the X.509 Key Usage extension: a multi-valued
>>>>>>>>>>>     property that declares the intended purpose of the JWT,
>>>>>>>>>>>     and that a recipient may refer to when determining
>>>>>>>>>>>     whether to accept a JWT being presented to it in some
>>>>>>>>>>>     context.
>>>>>>>>>>>      
>>>>>>>>>>>     -- 
>>>>>>>>>>>     "aud" (audience) specifies the target client, but not
>>>>>>>>>>>     the intended usage (access token to authorize resource
>>>>>>>>>>>     access or SET to communicate a security event?)
>>>>>>>>>>>      
>>>>>>>>>>>>>     <mailto:[email-masked]><mailto:[email-masked]
>>>>>>>>>>>>>     <mailto:[email-masked]>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>     <mailto:[email-masked]>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>     <mailto:[email-masked]><mailto:[email-masked]
>>>>>>>>>>>>>                          > With these requirements in mind
>>>>>>>>>>>>>     I propose the
>>>>>>>>>>>>>                         following:
>>>>>>>>>>>>>                          > - both "sub" and "iss" to be
>>>>>>>>>>>>>     defined at the event
>>>>>>>>>>>>>                         level
>>>>>>>>>>>>>                          > - "iss" at event level and at
>>>>>>>>>>>>>     top SET level can
>>>>>>>>>>>>>                         be different
>>>>>>>>>>>>>                          > - "iss" and "sub" at event
>>>>>>>>>>>>>     level can be different
>>>>>>>>>>>>>                         across events in the same SET

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 22 Jun 2017 13:06:25 -0700

Ben,

Well the event type is supposed to inform the client how to interpret its own payload. 

What we are discussing is whether SET should define subject addressing itself, partially, or not at all and leave it up to the event type profile. 

I would like to see strong standardization and consistency in the outer level jwt object to improve the interop. If subject addressing is at the top level then SET should be clear about its use. 

Phil

> On Jun 22, 2017, at 12:58 PM, Benjamin Kaduk <[email-masked]> wrote:
> 
> A very abstract concern I would have is that if you have some entity issuing SETs assuming one profile, how is it ensured that everything consuming those SETs interpret it using the same profile?  I know there are a lot of things deployed out there in the greater OAuth world that use out-of-band agreements between participants, but maybe we want to move away from that sort of thing.
> 
> -Ben
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Bdig6jCQcXk91JEeOcsSzadVRk9IgwZ5HRkh8f0EjfA&s=PnOQEkjo50Ss_9xMzvLfAShD4e4QDhX6LsSMHSX0f8Q&e=

---

From: Justin Richer <[email-masked]>
Date: Sun, 25 Jun 2017 10:31:10 -0400

Mike, this is not at all what I see for having the "most support". 
Instead I'm seeing a lot of call for having "sub" defined clearly in the 
event payload only.

The "sub" of the main body is the subject as known by the issuer of the 
SET itself. This might be the same subject that the subject is known by 
at the target of the SET. There are many cases where this isn't true, 
and so far one exception case where it is, sometimes. We should not be 
writing this for the exception.

But I think there's a pretty clear path forward. The "sub" in the body 
of a SET, if it is included, is *ALWAYS* in the context of the "iss" of 
the SET. Always, full stop, no exceptions. No global namespaces, no 
restrictions on content, no formats -- it's an opaque (to the SET 
standard) value in the domain of the issuer of the SET.

Event payloads, defined in profiles, describe a subject of the event 
itself. Importantly, this is the subject as known by the context in 
which the event will be *received*, not in which it was *issued*. 
Sometimes those are the same, more often (as we're seeing) we can't 
guarantee that. We should not depend on that and we should not treat the 
exceptional case as the usual, no matter what syntax another group has 
come up with.

So here's the thing. I think the "sub" of an event should be optional, 
and ALWAYS in the context of the issuer, and profiles should not places 
further constraints on that. Events themselves should be self-contained. 
I regret that we didn't make the registration object in RFC7591 more 
self-contained, as that's caused implementation and extension issues. I 
think events should always have an internal subject/issuer pair, in the 
context of where the event is being consumed. We need to define what 
iss/sub mean (in a grand sense) inside the event object in this 
document, so that different events don't reinvent the same thing over 
and over. If a profile wants to leave that out because they don't need 
an identifier for the payload, then they can leave it out. If they want 
to leave it out because they want to assume there will "always" be an 
iss/sub in the root of the SET, then I have a problem with that. The 
issuer of the SET can, and probably does, have its own identifier which 
can't be assumed to be universal. Proposing a global subject namespace 
or format, as has been suggested elsewhere on this list, is ludicrous 
and will never fly as it goes against how JWT namespacing for people and 
objects has always worked. We should have a clear semantic data 
structure that can be extended and used by all of the use cases that 
we've adopted. Optimizing at this stage, especially based on one event, 
is going to just lead to things being broken and back-patched later on. 
But if one spec wants to leave out the iss/sub inside the event? They 
can still do that, but I think that's pretty daft.

In summary:

  * iss: issuer of the event
  * sub: subject of the event as known by the issuer of the event
  * event.sub: subject of the event as known by the recipient of the event
  * event.iss: context for the subject of the event as known by the
    recipient of the event
  * event.aud: recipient of the event

  -- Justin

On 6/21/2017 7:45 PM, Mike Jones wrote:
>
> The proposal that I believe has the most support is keeping things as 
> they are, leaving it up to profiles and applications to define which 
> claims they use and how they use them.
>
> *Cc: *Marius Scurtescu <mailto:[email-masked]>; John Bradley 
> <mailto:[email-masked]>; Henk Birkholz 
> If the event type uses “sub” to identify its subject, and the issuer 
> of the subject is identical to the issuer for the event, then “sub” 
> may be used at the top level. Otherwise, the subject of an event (e.g. 
> “sub”) and any other claims required to uniquely identify the subject 
> MUST be contained in the event payload.
>
> https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 might 
> be identified in the event payload as: 
> “sub”:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4”
>
> A Connect Logout event from an OP uses the top level sub claim and 
> depends on “iss” being the same for the event issuer AND the subject. 
> This means that no party may issue logout events on behalf of the OP.
>
>
> Phil
>
> www.independentid.com <http://www.independentid.com>
>> single SET, then I’m less concerned about leaving sub semantics up to 
>> the profiles.
>> -- 
>> *From:*Marius Scurtescu <[email-masked] 
>> *Date:*Wednesday, June 21, 2017 at 2:58 PM
>> *To:*"Richard Backman, Annabelle" <[email-masked] 
>> *Cc:*"Phil Hunt (IDM)" <[email-masked] 
>> <[email-masked] <mailto:[email-masked]>>, Michael Jones 
>> <[email-masked] <mailto:[email-masked]>>, 
>> ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
>> *Subject:*Re: [Id-event] solution for Id/Access Token confusion and 
>> distinct SET issuer
>>> The spec says that the events claim SHOULD NOT be used to express 
>>> multiple logical events. If it’s also not used to express events 
>>> from different profiles that correspond to the same logical event 
>>> (e.g. an OIDC backchannel logout event alongside a hypothetical RISC 
>>> logout event), then I’m not sure what use case that leaves for 
>>> multiple events in one SET.
>>> -- 
>>> *From:*Id-event <[email-masked] 
>>> <mailto:[email-masked]>> on behalf of "Phil Hunt (IDM)" 
>>> *Date:*Wednesday, June 21, 2017 at 2:12 PM
>>> *To:*John Bradley <[email-masked] <mailto:[email-masked]>>
>>> *Cc:*"Richard Backman, Annabelle" <[email-masked] 
>>> *Subject:*Re: [Id-event] solution for Id/Access Token confusion and 
>>> distinct SET issuer
>>> backchannel logout very narrowly scoped. He suggested risc define 
>>> its own duplicate definitions and meanings.
>>> differentiators we had tried to make was an assumption that user 
>>> initiated events would be part of connect. Risk would cover 
>>> variations that drive off of risk calculations like password reset.
>>> There are also signout events at rp's to let the OP know. These are 
>>> not commands but notification that a resource session is cancelled. 
>>> IOW single sign out not expected.
>>>
>>> Phil
>>>
>>>
>>>> I thought we decided that we are only allowing set messages form 
>>>> the same family that agree on top level claims.
>>>>> I agree with John that the JWT type confusion problem and the SET 
>>>>> sub problem can and should be discussed separately. The secevents 
>>>>> WG is probably not the right setting to discuss the former.
>>>>> My concern with the sub claim is that two profiles may dictate 
>>>>> conflicting semantics (e.g. Profile A says it’s a phone number, 
>>>>> Profile B says it’s an email address). If these profiles don’t 
>>>>> provide an alternate way to declare subject of their events, then 
>>>>> they cannot be present within the same token. This incompatibility 
>>>>> trap seems like something that could be easily missed by groups 
>>>>> profiling SET.
>>>>> -- 
>>>>> *From:*John Bradley <[email-masked] <mailto:[email-masked]>>
>>>>> *Date:*Wednesday, June 21, 2017 at 1:39 PM
>>>>> *To:*Yaron Sheffer <[email-masked] 
>>>>> *Cc:*Justin Richer <[email-masked] <mailto:[email-masked]>>, 
>>>>> Marius Scurtescu <[email-masked] 
>>>>> <mailto:[email-masked]>>, Annabelle Richard 
>>>>> <[email-masked] <mailto:[email-masked]>>, Phil Hunt 
>>>>> *Subject:*Re: [Id-event] solution for Id/Access Token confusion 
>>>>> and distinct SET issuer
>>>>> application/idt+jwt if we register jwt as a structured name sufix.
>>>>> confusion around JWT for different purposes, we should just start 
>>>>> using the typ parameter based on the existing spec.
>>>>> If sub is not allowed at the top level people will do non SET JWT 
>>>>> for things where the subject is scoped to the iss of the token.
>>>>> I think defining sub to be part of the event for cases where the 
>>>>> sub is scoped differently from the issuer of the token is fine, 
>>>>> but should not be required for all event types.
>>>>>> Almost everybody agrees on a long-term "usage" claim ("type" is 
>>>>>> taken) that should be defined elsewhere, e.g. in the JWT BCP.
>>>>>> Did I miss anything?
>>>>>> By the way, if we do add a "usage" claim, we need to also use it 
>>>>>> in the SET document before it is published.
>>>>>> Thanks,
>>>>>>     Yaron
>>>>>>>> Also, Mike you are missing the other requirement, for RPs to 
>>>>>>>> send events to an IdP. The iss+sub pair at the top level is 
>>>>>>>> broken in this case.
>>>>>>>>
>>>>>>>> Marius
>>>>>>>>>> Your explanation for why this is a non-problem is dependent 
>>>>>>>>>> upon side effects of elements of OpenID Connect that were not 
>>>>>>>>>> designed to solve this issue. As a result, I see several 
>>>>>>>>>> issues with it:
>>>>>>>>>>
>>>>>>>>>> 1.The caller of the Token Endpoint is the only party that can 
>>>>>>>>>> be certain that a nonce-less ID Token is really an ID Token. 
>>>>>>>>>> Any party that the caller passes the ID Token off to has no 
>>>>>>>>>> way to verify its provenance.
>>>>>>>>>>
>>>>>>>>>> 4.This is only a solution for ID Tokens. Every other JWT 
>>>>>>>>>> profile that cares about disambiguation has to invent its own 
>>>>>>>>>> solution to the problem.
>>>>>>>>>>
>>>>>>>>>> attacks are both things that happen. What’s being proposed is 
>>>>>>>>>> a simple, defensive measure against these risks. You brought 
>>>>>>>>>> up JWT libraries: a general solution actually makes it easier 
>>>>>>>>>> to use common libraries for JWT parsing. A “usage-aware” JWT 
>>>>>>>>>> library could handle disambiguation for any JWT profile, 
>>>>>>>>>> *From:*Id-event <[email-masked] 
>>>>>>>>>> *Date:*Wednesday, June 14, 2017 at 1:16 PM
>>>>>>>>>> *To:*Marius Scurtescu <[email-masked] 
>>>>>>>>>> *Cc:*"Richard Backman, Annabelle" <[email-masked] 
>>>>>>>>>> *Subject:*Re: [Id-event] solution for Id/Access Token 
>>>>>>>>>> You’ve heard of “premature optimization”. I’d characterize 
>>>>>>>>>> the proposals in this thread as “premature pessimation” – 
>>>>>>>>>> making things that can and should be simple complex, without 
>>>>>>>>>> data showing there’s any need to do so.
>>>>>>>>>> have.  It’s already been established that it’s impossible for 
>>>>>>>>>> a SET to be confused for an ID Token – 
>>>>>>>>>> seehttps://www.ietf.org/mail-archive/web/id-event/current/msg00428.html 
>>>>>>>>>> deployments, please provide specifics, so that we can use 
>>>>>>>>>> that data to inform appropriate engineering choices on our part.
>>>>>>>>>> “sub” in the normal way, or requiring a type claim, would 
>>>>>>>>>> make previously simple things unnecessarily complex.  Yes, 
>>>>>>>>>> then the result is then different than a normal JWT but a 
>>>>>>>>>> consequence of this is that custom parsing code would have to 
>>>>>>>>>> be used, rather than a standard JWT parser.  The more 
>>>>>>>>>> unwieldy we make it to use SETs, the more likely developers 
>>>>>>>>>> are to just create their own data structures. Keeping it 
>>>>>>>>>> simple is the key to adoption. Standards are only useful if 
>>>>>>>>>> they are actually used.
>>>>>>>>>> -- Mike
>>>>>>>>>> *From:*Id-event [mailto:[email-masked]]*On Behalf 
>>>>>>>>>> Of*Richard Backman, Annabelle
>>>>>>>>>> *Sent:*Tuesday, June 13, 2017 5:33 PM
>>>>>>>>>> *To:*Marius Scurtescu <[email-masked] 
>>>>>>>>>> *Cc:*ID Events Mailing List <[email-masked] 
>>>>>>>>>> *Subject:*Re: [Id-event] solution for Id/Access Token 
>>>>>>>>>> X.509 Key Usage extension: a multi-valued property that 
>>>>>>>>>> declares the intended purpose of the JWT, and that a 
>>>>>>>>>> recipient may refer to when determining whether to accept a 
>>>>>>>>>> JWT being presented to it in some context.
>>>>>>>>>> -- 
>>>>>>>>>> *From:*Id-event <[email-masked] 
>>>>>>>>>> *Date:*Tuesday, June 13, 2017 at 11:05 AM
>>>>>>>>>> *To:*Henk Birkholz <[email-masked] 
>>>>>>>>>> *Cc:*ID Events Mailing List <[email-masked] 
>>>>>>>>>> *Subject:*Re: [Id-event] solution for Id/Access Token 
>>>>>>>>>> intended usage (access token to authorize resource access or 
>>>>>>>>>> SET to communicate a security event?)
>>>>>>>>>>>> unrecognized claim” approach to ensure that JWTs from some 
>>>>>>>>>>>> ·It is unrealistic to expect implementers to adhere to the 
>>>>>>>>>>>> “different keys for different kinds of JWTs” rule. Whether 
>>>>>>>>>>>> mandated by the spec or not, implementers will ignore this 
>>>>>>>>>>>> because managing one key is easier than managing N 
>>>>>>>>>>>> different keys.
>>>>>>>>>>>>
>>>>>>>>>>>> <mailto:[email-masked]>> on behalf of Dick Hardt 
>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>>>>>>>>> <mailto:[email-masked]>>, "matake, nov" <[email-masked] 
>>>>>>>>>>>> <mailto:[email-masked]>>, ID Events Mailing List 
>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>>, "Phil Hunt 
>>>>>>>>>>>> <mailto:[email-masked]><mailto:[email-masked] 
>>>>>>>>>>>> <mailto:[email-masked]><mailto:[email-masked] 
>>>>>>>>>>>> <mailto:[email-masked]><mailto:[email-masked] 
>>>>>>>>>>>> <mailto:[email-masked]>
>>>>>>>>>>>> <mailto:[email-masked]><mailto:[email-masked]

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 26 Jun 2017 09:43:00 -0700

Justin, in the case when an RP is issuing the SET to send it to an IdP, a
top level sub as you describe it may not be possible. Or maybe I
misunderstand.

We agree on "iss" I think, in this case it points to the RP. A top level
"sub" though is problematic, The RP in many cases has the opaque "sub" as
issued by the IdP, but this value is globally unique only when combined
with the IdP "iss".

Not sure why event.aud would be necessary?

Marius

On Sun, Jun 25, 2017 at 7:31 AM, Justin Richer <[email-masked]> wrote:

> Mike, this is not at all what I see for having the "most support". Instead
> I'm seeing a lot of call for having "sub" defined clearly in the event
> payload only.
>
> SET itself. This might be the same subject that the subject is known by at
> the target of the SET. There are many cases where this isn't true, and so
> far one exception case where it is, sometimes. We should not be writing
> this for the exception.
>
> But I think there's a pretty clear path forward. The "sub" in the body of
> a SET, if it is included, is *ALWAYS* in the context of the "iss" of the
> SET. Always, full stop, no exceptions. No global namespaces, no
> restrictions on content, no formats -- it's an opaque (to the SET standard)
> value in the domain of the issuer of the SET.
>
> itself. Importantly, this is the subject as known by the context in which
> the event will be *received*, not in which it was *issued*. Sometimes those
> are the same, more often (as we're seeing) we can't guarantee that. We
> should not depend on that and we should not treat the exceptional case as
> the usual, no matter what syntax another group has come up with.
>
> So here's the thing. I think the "sub" of an event should be optional, and
> ALWAYS in the context of the issuer, and profiles should not places further
> constraints on that. Events themselves should be self-contained. I regret
> that we didn't make the registration object in RFC7591 more self-contained,
> as that's caused implementation and extension issues. I think events should
> always have an internal subject/issuer pair, in the context of where the
> event is being consumed. We need to define what iss/sub mean (in a grand
> sense) inside the event object in this document, so that different events
> don't reinvent the same thing over and over. If a profile wants to leave
> that out because they don't need an identifier for the payload, then they
> can leave it out. If they want to leave it out because they want to assume
> there will "always" be an iss/sub in the root of the SET, then I have a
> problem with that. The issuer of the SET can, and probably does, have its
> own identifier which can't be assumed to be universal. Proposing a global
> subject namespace or format, as has been suggested elsewhere on this list,
> is ludicrous and will never fly as it goes against how JWT namespacing for
> people and objects has always worked. We should have a clear semantic data
> structure that can be extended and used by all of the use cases that we've
> adopted. Optimizing at this stage, especially based on one event, is going
> to just lead to things being broken and back-patched later on. But if one
> spec wants to leave out the iss/sub inside the event? They can still do
> that, but I think that's pretty daft.
>
>
> In summary:
>
>    - iss: issuer of the event
>    - sub: subject of the event as known by the issuer of the event
>    - event.sub: subject of the event as known by the recipient of the
>    event
>    - event.iss: context for the subject of the event as known by the
>    recipient of the event
>    - event.aud: recipient of the event
>
>
>  -- Justin
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 26 Jun 2017 10:01:52 -0700

I would prefer a rule where sub and iss are *always* in the same location.

If we have to have all these if-then exceptions that limits use and increase complexities.

IMO - “sub” in the top level was designed for a specific domain of use.  While some SET usage can align, that’s not necessarily a good thing. The alignment further serves to make it harder to distinguish SETs for access and ID Tokens.

I keep coming back to consistency for all SETs as being less complex and open to wider usage.

Phil

> On Jun 26, 2017, at 9:43 AM, Marius Scurtescu <[email-masked]> wrote:
> 
> Justin, in the case when an RP is issuing the SET to send it to an IdP, a top level sub as you describe it may not be possible. Or maybe I misunderstand.
> 
> We agree on "iss" I think, in this case it points to the RP. A top level "sub" though is problematic, The RP in many cases has the opaque "sub" as issued by the IdP, but this value is globally unique only when combined with the IdP "iss".
> 
> On Sun, Jun 25, 2017 at 7:31 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> Mike, this is not at all what I see for having the "most support". Instead I'm seeing a lot of call for having "sub" defined clearly in the event payload only.
> 
> The "sub" of the main body is the subject as known by the issuer of the SET itself. This might be the same subject that the subject is known by at the target of the SET. There are many cases where this isn't true, and so far one exception case where it is, sometimes. We should not be writing this for the exception.
> 
> But I think there's a pretty clear path forward. The "sub" in the body of a SET, if it is included, is *ALWAYS* in the context of the "iss" of the SET. Always, full stop, no exceptions. No global namespaces, no restrictions on content, no formats -- it's an opaque (to the SET standard) value in the domain of the issuer of the SET. 
> 
> Event payloads, defined in profiles, describe a subject of the event itself. Importantly, this is the subject as known by the context in which the event will be *received*, not in which it was *issued*. Sometimes those are the same, more often (as we're seeing) we can't guarantee that. We should not depend on that and we should not treat the exceptional case as the usual, no matter what syntax another group has come up with. 
> 
> So here's the thing. I think the "sub" of an event should be optional, and ALWAYS in the context of the issuer, and profiles should not places further constraints on that. Events themselves should be self-contained. I regret that we didn't make the registration object in RFC7591 more self-contained, as that's caused implementation and extension issues. I think events should always have an internal subject/issuer pair, in the context of where the event is being consumed. We need to define what iss/sub mean (in a grand sense) inside the event object in this document, so that different events don't reinvent the same thing over and over. If a profile wants to leave that out because they don't need an identifier for the payload, then they can leave it out. If they want to leave it out because they want to assume there will "always" be an iss/sub in the root of the SET, then I have a problem with that. The issuer of the SET can, and probably does, have its own identifier which can't be assumed to be universal. Proposing a global subject namespace or format, as has been suggested elsewhere on this list, is ludicrous and will never fly as it goes against how JWT namespacing for people and objects has always worked. We should have a clear semantic data structure that can be extended and used by all of the use cases that we've adopted. Optimizing at this stage, especially based on one event, is going to just lead to things being broken and back-patched later on. But if one spec wants to leave out the iss/sub inside the event? They can still do that, but I think that's pretty daft.
> 
> 
> 
> In summary:
> 
> iss: issuer of the event
> sub: subject of the event as known by the issuer of the event
> event.sub: subject of the event as known by the recipient of the event
> event.iss: context for the subject of the event as known by the recipient of the event
> event.aud: recipient of the event
> 
> 
>  -- Justin
> 
> 
>> From: Phil Hunt <mailto:[email-masked]>
>> To: Richard Backman, Annabelle <mailto:[email-masked]>
>> Cc: Marius Scurtescu <mailto:[email-masked]>; John Bradley <mailto:[email-masked]>; Henk Birkholz <mailto:[email-masked]>; Justin Richer <mailto:[email-masked]>; Yaron Sheffer <mailto:[email-masked]>; Mike Jones <mailto:[email-masked]>; ID Events Mailing List <mailto:[email-masked]>
>> A SCIM resource URI of https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 <https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4> might be identified in the event payload as: “sub”:"https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4 <https://scim.example.com/users/ac1faebbfd3c45ce9a242bd3859c82c4>”
>> 
>> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=5nEWLHNlT6T5AGTIYqLOHQWDsyMU6aBF12pECG2xhHM&s=UhoAQmpJ0QMVgVUkW1TR6-lhKLkJfFa_81Mk-_nllOc&e=>[email-masked] <mailto:[email-masked]>
>>> On Jun 21, 2017, at 3:38 PM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> From: Marius Scurtescu <[email-masked] <mailto:[email-masked]>>
>>> To: "Richard Backman, Annabelle" <[email-masked] <mailto:[email-masked]>>
>>> Cc: "Phil Hunt (IDM)" <[email-masked] <mailto:[email-masked]>>, John Bradley <[email-masked] <mailto:[email-masked]>>, Henk Birkholz <[email-masked] <mailto:[email-masked]>>, Justin Richer <[email-masked] <mailto:[email-masked]>>, Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, Michael Jones <[email-masked] <mailto:[email-masked]>>, ID Events Mailing List <[email-masked] <mailto:[email-masked]>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=5nEWLHNlT6T5AGTIYqLOHQWDsyMU6aBF12pECG2xhHM&s=G9H4qR9aSCbjpURD9Ear_fgjhUkH_n-3V1CZMkIOc_8&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=5nEWLHNlT6T5AGTIYqLOHQWDsyMU6aBF12pECG2xhHM&s=G9H4qR9aSCbjpURD9Ear_fgjhUkH_n-3V1CZMkIOc_8&e=>

---

From: Mike Jones <[email-masked]>
Date: Mon, 26 Jun 2017 17:05:25 +0000

Justin,

The rules you’re proposing may be fine for a SET profile for a particular kind of application.  I encourage you to join the RISC working group and work on them there.  But they would limit the use cases that SETs could be used for, which would be unfortunate and unnecessary.

An analogy with JWT is illustrative.  JWT is intentionally general-purpose, leaving it up to application profiles what claims to use and what their semantics are.  This enables JWTs to be used for ID Tokens<http://openid.net/specs/openid-connect-core-1_0.html#IDToken> and also for completely unrelated uses, such as SIP<https://tools.ietf.org/html/rfc8055> and Caller ID<https://tools.ietf.org/html/draft-ietf-stir-passport-11>.  There is no expectation of interoperability between these different JWT applications.  Indeed – both the syntax *and the semantics*, such has how to determine what keys are valid, are different.  It’s this flexibility that makes JWTs general-purpose.

Likewise, SET as currently specified is similarly general-purpose.  Application profiles define what SET claims to use and their semantics.  There is no expectation of interoperability between different SET profiles, nor should there be, as their applications are different.  Trying to make SETs require choices appropriate to a particular profile will necessarily make them a poor or impossible fit for others.  This would be a very bad thing.

Ironically, “locking down” SET to require choices motivated by a particular profile wouldn’t help that profile at all, as it would work the same whether SET was “locked down” or not.  But it would unnecessarily preclude use of SETs in other contexts that they are currently a great fit for.

                                                                -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Monday, June 26, 2017 9:43 AM
To: Justin Richer <[email-masked]>
Cc: Mike Jones <[email-masked]>; Phil Hunt <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; John Bradley <[email-masked]>; Henk Birkholz <[email-masked]>; Yaron Sheffer <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

Marius

On Sun, Jun 25, 2017 at 7:31 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

In summary:

  *   event.iss: context for the subject of the event as known by the recipient of the event

 -- Justin

– Mike

Phil

Marius

Phil

John B.

John B.

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

Id-event mailing list

---

From: Phil Hunt <[email-masked]>
Date: Mon, 26 Jun 2017 10:13:20 -0700

Phil

> On Jun 26, 2017, at 10:05 AM, Mike Jones <[email-masked]> wrote:
> 
> Justin,
>  
> An analogy with JWT is illustrative.  JWT is intentionally general-purpose, leaving it up to application profiles what claims to use and what their semantics are.  This enables JWTs to be used for ID Tokens <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dcore-2D1-5F0.html-23IDToken&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ajIy8Fp7TzNHe30cIwl2AR6GEWnbTZ7BrC3rsUdOAzQ&s=Jg-KrA7IAdxpWgSftvWiHha8MWrn0_dNNpT0if4N8TM&e=> and also for completely unrelated uses, such as SIP <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8055&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ajIy8Fp7TzNHe30cIwl2AR6GEWnbTZ7BrC3rsUdOAzQ&s=egsNQiqQHe0R8Lnw8i5vbvQ8flXk4pOLliLiOoeEHEE&e=> and Caller ID <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dstir-2Dpassport-2D11&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ajIy8Fp7TzNHe30cIwl2AR6GEWnbTZ7BrC3rsUdOAzQ&s=AshRSt1zrJ8y99eqNshYuE73oDBO8PA7AT7SjxDnkdk&e=>.  There is no expectation of interoperability between these different JWT applications.  Indeed – both the syntax *and the semantics*, such has how to determine what keys are valid, are different.  It’s this flexibility that makes JWTs general-purpose.
>  

-1 is not a strong enough expression here.

The whole point of this WG is to have a comment message and transfer format.  Each profile can define events of different meaning but to have JWT processing that is dramatically different and complex would be a negative outcome that kills the value of this working group.

If people find the need to extend messaging protocols (e.g. to introduce things like complex error signalling). They are not doing events right.

If this is truly the WG decision, we are back to RISC specific, SCIM specific, Session specific, OAuth specific event protocols and formats.  Yet many participants will all have these systems interconnected to our security systems which are all evolving over time.  Having 5 or 6 connectors coupled with inconsistent implementation leads us no-way. It means we will not be communicating with each other to help our customers unless we pay the high costs of custom connectors and cross-license each silo’s proprietary API.

The whole point of a standard is to make this possible, not to create a barrier to security.

Lack of common inter-op between systems and silos is a HUGE loss.

This is also the lesson learned from TAXII.  They did not have a strong standard and it failed because there is no implementable common platform.

> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ajIy8Fp7TzNHe30cIwl2AR6GEWnbTZ7BrC3rsUdOAzQ&s=wRI9Y9NKt4D_bL4YdOM07k4s-fiDla80uUkW2fyAUms&e=>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 26 Jun 2017 10:13:46 -0700

Limit use cases, in what ways?

The format is a bit more complex, yes, but that is not limiting anything.
By defining a simpler base SET and then requiring the most important
profiles to make it more complex anyhow is not helping at all IMO. As Phil
mentioned, I think consistency is more important.

But again, if use cases are indeed limited then please clarify how.

Marius

On Mon, Jun 26, 2017 at 10:05 AM, Mike Jones <[email-masked]>
wrote:

> Justin,
>
>
>
> The rules you’re proposing may be fine for a SET profile for a particular
> kind of application.  I encourage you to join the RISC working group and
> work on them there.  But they would limit the use cases that SETs could be
> used for, which would be unfortunate and unnecessary.
>
>
>
> An analogy with JWT is illustrative.  JWT is intentionally
> general-purpose, leaving it up to application profiles what claims to use
> and what their semantics are.  This enables JWTs to be used for ID Tokens
> <http://openid.net/specs/openid-connect-core-1_0.html#IDToken> and also
> for completely unrelated uses, such as SIP
> <https://tools.ietf.org/html/rfc8055> and Caller ID
> <https://tools.ietf.org/html/draft-ietf-stir-passport-11>.  There is no
> expectation of interoperability between these different JWT applications.
> Indeed – both the syntax **and the semantics**, such has how to determine
> what keys are valid, are different.  It’s this flexibility that makes JWTs
> general-purpose.
>
>
>
> Likewise, SET as currently specified is similarly general-purpose.
> Application profiles define what SET claims to use and their semantics.  *There
> is no expectation of interoperability between different SET profiles, nor
> should there be*, as their applications are different.  Trying to make
> SETs require choices appropriate to a particular profile will necessarily
> make them a poor or impossible fit for others.  This would be a very bad
> thing.
>
>
>
> Ironically, “locking down” SET to require choices motivated by a
> particular profile wouldn’t help that profile at all, as it would work the
> same whether SET was “locked down” or not.  But it would unnecessarily
> preclude use of SETs in other contexts that they are currently a great fit
> for.
>
>
>
>                                                                 -- Mike
>
>
>
> *Sent:* Monday, June 26, 2017 9:43 AM
> *To:* Justin Richer <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; Phil Hunt <
> [email-masked]>; Richard Backman, Annabelle <[email-masked]>;
> John Bradley <[email-masked]>; Henk Birkholz <
> [email-masked]>; Yaron Sheffer <[email-masked]>;
> ID Events Mailing List <[email-masked]>
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 26 Jun 2017 17:19:24 +0000

It would limit use cases in the same way that, if the authors of JWT (who were also the authors of the ID Token), “locked down” JWTs so that they all used the same claims and semantics of ID Tokens, then the SIP<https://tools.ietf.org/html/rfc8055> and Caller ID<https://tools.ietf.org/html/draft-ietf-stir-passport-11> JWT profiles would have never come into existence.  JWTs would have still worked for ID Tokens, but we would have needlessly foreclosed other possibilities we couldn’t even imagine, which are just as legitimate.

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Monday, June 26, 2017 10:14 AM
To: Mike Jones <[email-masked]>
Cc: Justin Richer <[email-masked]>; Phil Hunt <[email-masked]>; Richard Backman, Annabelle <[email-masked]>; John Bradley <[email-masked]>; Henk Birkholz <[email-masked]>; Yaron Sheffer <[email-masked]>; ID Events Mailing List <[email-masked]>
Subject: Re: [Id-event] solution for Id/Access Token confusion and distinct SET issuer

The format is a bit more complex, yes, but that is not limiting anything. By defining a simpler base SET and then requiring the most important profiles to make it more complex anyhow is not helping at all IMO. As Phil mentioned, I think consistency is more important.

Marius

On Mon, Jun 26, 2017 at 10:05 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Justin,

                                                                -- Mike

From: Marius Scurtescu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, June 26, 2017 9:43 AM
To: Justin Richer <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>; Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>>; John Bradley <[email-masked]<mailto:[email-masked]>>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; ID Events Mailing List <[email-masked]<mailto:[email-masked]>>

Marius

In summary:

 -- Justin

– Mike

Phil

Marius

Phil

John B.

John B.

 — Justin

Marius

Phil

                                                -- Mike

Henk

--

Identity Services

    Marius

                +1 especially for "type"

                    +1

                    Phil

--

Id-event mailing list

---

From: Justin Richer <[email-masked]>
Date: Mon, 26 Jun 2017 15:32:25 -0400

Mike,

I disagree with that assessment and think you’re drawing a false equivalence. SET *should* be limited to a semantically related set of items. Otherwise, what’s the point of a standard? It would just be “oh just everyone use JWTs for different things”. 

It sounds like what you want from this group is to declare an “event” top-level claim and then get out of the way. I don’t think that’s useful on its own, nor is it the best we can do. 

I think the rules I laid out are applicable to all of the use cases that have been brought up here so far. RISC isn’t the right place to have this discussion — this list is.

 — Justin

> On Jun 26, 2017, at 1:05 PM, Mike Jones <[email-masked]> wrote:
> 
> Justin,
>  
> An analogy with JWT is illustrative.  JWT is intentionally general-purpose, leaving it up to application profiles what claims to use and what their semantics are.  This enables JWTs to be used for ID Tokens <http://openid.net/specs/openid-connect-core-1_0.html#IDToken> and also for completely unrelated uses, such as SIP <https://tools.ietf.org/html/rfc8055> and Caller ID <https://tools.ietf.org/html/draft-ietf-stir-passport-11>.  There is no expectation of interoperability between these different JWT applications.  Indeed – both the syntax *and the semantics*, such has how to determine what keys are valid, are different.  It’s this flexibility that makes JWTs general-purpose.
>  
> www.independentid.com <http://www.independentid.com/>