Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

From: "M.Lizar@OCG" <[email-masked]>
Date: Tue, 1 Aug 2017 12:17:42 -0400

+1 on existing text . 

Agree the document is ready to publish

- Mark

> On 31 Jul 2017, at 16:53, Mike Jones <[email-masked]> wrote:
> 
> I believe that the specification is ready to publish as-is.  It already meets the needs of the known use cases and is in production use.
>  
>                                                                 -- Mike
>  
> From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
> Sent: Monday, July 31, 2017 1:40 PM
> To: SecEvent <[email-masked]>
> Subject: [Id-event] WG Last Call for draft-ietf-secevent-token-02
>  
> This is to announce working group last call on this draft (https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ <https://datatracker.ietf.org/doc/draft-ietf-secevent-token/>).
> 
> Please send your comments to the list. Even if you are perfectly happy with the draft, please let us know that you support its publication as-is by posting to the list.
> 
> Because of the summer holidays, this last call is open for 3 weeks, until Aug. 21.
> 
> Thanks,
>     Dick and Yaron
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Nat Sakimura <[email-masked]>
Date: Wed, 02 Aug 2017 17:07:12 +0000

Thanks, it looks generally good. I had only three small nits.

*1) "MUST NOT" in the introduction. *
---------------------------------------------------
I feel that it is better to have this MUST NOT in the main text. The
introduction often is skipped by a reader.

*2) Potentially missing "defined in " in Section 2 the first bullet*
------------------------------------------------------------------------------------------------------
There seems to be missing "defined in" in the sentence "the JWT Token
Claims Registry Section 10.1".

*3) Issuer validation*
----------------------------------
I am not sure how to do an issuer validation when using unsecured JWT.
Adding more explanation would be beneficial.

Best,

Nat

On Wed, Aug 2, 2017 at 1:18 AM M.Lizar@OCG <[email-masked]>
wrote:

> I believe that the specification is ready to publish as-is.  It already
> meets the needs of the known use cases and is in production use.
>
>                                                                 -- Mike
>
> *From:* Id-event [mailto:[email-masked]
> <[email-masked]>] *On Behalf Of *Yaron Sheffer
> *Sent:* Monday, July 31, 2017 1:40 PM
> *To:* SecEvent <[email-masked]>
> *Subject:* [Id-event] WG Last Call for draft-ietf-secevent-token-02
>
>
> This is to announce working group last call on this draft (
> https://datatracker.ietf.org/doc/draft-ietf-secevent-token/).
>
> Please send your comments to the list. Even if you are perfectly happy
> with the draft, please let us know that you support its publication as-is
> by posting to the list.
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Phil Hunt <[email-masked]>
Date: Wed, 2 Aug 2017 10:26:42 -0700

Nat,

Thanks for the read.

For #1 - should we move that paragraph to section 2 and leave some more generalized statement in section 1?

For #2 - I think the paragraph starting “An outer JSON object that acts…” could be improved. Agreed that something along the lines of defined in JWT should be used.

I recall #3 came up before as part of the delivery spec discussions.  My intent is that when using unsecured JWTs the receiver has to validate via the method of delivery.  E.g. was the JWT delivered over a mutually authenticated channel?

Section 4.1 and 4.2 covers the issue albeit indirectly.

I will go over the text and see what improvement could be made - probably in security considerations.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Aug 2, 2017, at 10:07 AM, Nat Sakimura <[email-masked]> wrote:
> 
> 1) "MUST NOT" in the introduction. 
> I feel that it is better to have this MUST NOT in the main text. The introduction often is skipped by a reader. 
> 
> 2) Potentially missing "defined in " in Section 2 the first bullet
> There seems to be missing "defined in" in the sentence "the JWT Token Claims Registry Section 10.1".
> 
> 3) Issuer validation
> On Wed, Aug 2, 2017 at 1:18 AM M.Lizar@OCG <[email-masked] <mailto:[email-masked]>> wrote:
> +1 on existing text . 
> 
>> On 31 Jul 2017, at 16:53, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Yaron Sheffer
>> To: SecEvent <[email-masked] <mailto:[email-masked]>>
>> This is to announce working group last call on this draft (https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Nj4D94_Z5TX7aZpILIENbLknqDGinZlFUseKss9KZyY&s=34V_EUmT5gCZRmlH04kADdidPjoaKQgvob9KTHAK0Y0&e=>).
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/id-event <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Nj4D94_Z5TX7aZpILIENbLknqDGinZlFUseKss9KZyY&s=jgy3vjdjQKBEXv9AoYCSJ76EnSrAP9cnVXeoCkGMY9o&e=>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Nj4D94_Z5TX7aZpILIENbLknqDGinZlFUseKss9KZyY&s=jgy3vjdjQKBEXv9AoYCSJ76EnSrAP9cnVXeoCkGMY9o&e=>
> -- 
> Nat Sakimura
> 
> [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=Nj4D94_Z5TX7aZpILIENbLknqDGinZlFUseKss9KZyY&s=jgy3vjdjQKBEXv9AoYCSJ76EnSrAP9cnVXeoCkGMY9o&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=Nj4D94_Z5TX7aZpILIENbLknqDGinZlFUseKss9KZyY&s=jgy3vjdjQKBEXv9AoYCSJ76EnSrAP9cnVXeoCkGMY9o&e=>

---

From: Adam Dawes <[email-masked]>
Date: Wed, 2 Aug 2017 11:12:05 -0700

I believe this is ready for publication. Google will be making changes to
our proto RISC implementation to conform and will be looking forward to
getting real-world feedback on the spec.

On Wed, Aug 2, 2017 at 10:26 AM, Phil Hunt <[email-masked]> wrote:

> For #2 - I think the paragraph starting “An outer JSON object that acts…”
> could be improved. Agreed that something along the lines of defined in JWT
> should be used.
>
> I recall #3 came up before as part of the delivery spec discussions.  My
> intent is that when using unsecured JWTs the receiver has to validate via
> the method of delivery.  E.g. was the JWT delivered over a mutually
> authenticated channel?
>
> www.independentid.com
> [email-masked]
> ------------------------------------------------------------
> ------------------------------------------
>> https://datatracker.ietf.org/doc/draft-ietf-secevent-token/
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Nj4D94_Z5TX7aZpILIENbLknqDGinZlFUseKss9KZyY&s=34V_EUmT5gCZRmlH04kADdidPjoaKQgvob9KTHAK0Y0&e=>
>> ).
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Nj4D94_Z5TX7aZpILIENbLknqDGinZlFUseKss9KZyY&s=jgy3vjdjQKBEXv9AoYCSJ76EnSrAP9cnVXeoCkGMY9o&e=>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Nj4D94_Z5TX7aZpILIENbLknqDGinZlFUseKss9KZyY&s=jgy3vjdjQKBEXv9AoYCSJ76EnSrAP9cnVXeoCkGMY9o&e=>
>>
> --
>
> Nat Sakimura
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Nj4D94_
> Z5TX7aZpILIENbLknqDGinZlFUseKss9KZyY&s=jgy3vjdjQKBEXv9AoYCSJ76EnSrAP9
> cnVXeoCkGMY9o&e=
>
>
>

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

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 2 Aug 2017 18:43:29 +0000

Thanks for all the work on this! It was my understanding that there was an open item from Prague regarding whether to explicitly declare the events’ profiling specification in the SET. Has this been discussed further, or do we still need to close on it?

I have several comments/questions on the current draft:

  1.  “Profile Specification” vs. “Profiling Specification”
There are a handful of instances of the former that need to be changed to the latter, to match the term as defined in section 1.2:
     *   In the “sub” definition in section 1.2
     *   In section 3
     *   In section 4.2
  2.  Note regarding Subject Issuer vs. SET Issuer
The note regarding the potential for Subject and SET Issuer mismatch (in the “iss” definition in section 1.2) is I think more prescriptive than intended. As written, it mandates placing the Subject’s Issuer in an “iss” value within the event payload, but does not define a format or structure for this value. The logical format – that of the “iss” JWT claim – may or may not be appropriate, depending on the nature of the event and its Subject. I suggest removing this note and covering this concern elsewhere (see #4 below, re: Subject Identification).

  3.  Explicit Typing of SETs
I suggest removing the text “if the SET could be used in an application context in which it could be confused with other kinds of JWTs” from the first paragraph of section 2.2, making the secevent+jwt typ header mandatory to implement for all SETs. This conditional is impossible to evaluate, as new types of JWTs will be introduced over time. Just considering existing JWTs, it is a lot to ask for Profiling Spec authors to fully examine the contents and usage of every existing JWT. Mandating use of typ for SETs takes this load off of Profiling Spec authors and insures that future specs have a consistent, reliable way to defend against JWT type confusion.

  4.  Requirements for SET Profiles: Subject Identification
I suggest adding text along the lines of “Profiling Specifications MUST define for each of their events how the Subject is identified in the SET, as well as how to address conflicts the event Subject’s Issuer and the SET Issuer if applicable. It is NOT RECOMMENDED for Profiling Specifications to use the “sub” claim in cases where the Subject is not globally unique and has a different Issuer from the SET itself.”

  5.  Guidance for Signing SETs
The text in the last paragraph of section 4.1 is unclear to me. It seems to suggest that it is safe to send unsigned JWTs over a channel that lacks transport-layer security, so long as requests include a bearer token or use Basic Authentication. Am I misreading this? It seems counter to the guidance given earlier in the same section.

  6.  Distinguishing SETs from other kinds of JWTs
The last sentence of the first paragraph of section 4.7 seems impossible to me. Profiling Specifications cannot be solely responsible for ensuring incompatibility with all future JWT profiles. They can at best ensure incompatibility with existing JWT profiles and be compatible with a standard mechanism by which future JWT profiles may ensure incompatibility (e.g. the “secevent+jwt” typ header). It may be enough to strike the “(or other)” text from this sentence.

--
Annabelle Richard Backman
Identity Services

From: Id-event <[email-masked]> on behalf of "M.Lizar@OCG" <[email-masked]>
Date: Tuesday, August 1, 2017 at 9:17 AM
To: Mike Jones <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

+1 on existing text .

- Mark

On 31 Jul 2017, at 16:53, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                                -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Monday, July 31, 2017 1:40 PM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: [Id-event] WG Last Call for draft-ietf-secevent-token-02

This is to announce working group last call on this draft (https://datatracker.ietf.org/doc/draft-ietf-secevent-token/).

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

---

From: Phil Hunt <[email-masked]>
Date: Wed, 2 Aug 2017 12:22:48 -0700

Annabelle,

Thanks for the comments. Many of these items have been discussed at length but many members strongly want to leave as is.  I’ll await further group discussion.

Re: item 5 - I think I need to re-write that based on feedback from Nat and Marius.  Stay tuned.

Some of these items are also being discussed in the new JWT BCP document.  Maybe we should hold the SET Token spec so we can refer to the BCP and publish together?  That said, I know many want this finalized ASAP.

Phil

> On Aug 2, 2017, at 11:43 AM, Richard Backman, Annabelle <[email-masked] <mailto:[email-masked]>> wrote:
> 
> “Profile Specification” vs. “Profiling Specification”
> In the “sub” definition in section 1.2
> In section 3
> In section 4.2
> Note regarding Subject Issuer vs. SET Issuer
> Explicit Typing of SETs
> Requirements for SET Profiles: Subject Identification
> Guidance for Signing SETs
> Distinguishing SETs from other kinds of JWTs
> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of "M.Lizar@OCG" <[email-masked] <mailto:[email-masked]>>
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>, SecEvent <[email-masked] <mailto:[email-masked]>>
>> This is to announce working group last call on this draft (https://datatracker.ietf.org/doc/draft-ietf-secevent-token/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=FztSyO9IdR2ly2Cwmu1RhMdXDKw1epjGp_4pel_o_pg&s=NcFFmLZ6aFDT27EoSTD7rkP2m2nktWqgSd3_CPep8Uw&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=FztSyO9IdR2ly2Cwmu1RhMdXDKw1epjGp_4pel_o_pg&s=YwxW95s5oIBrBLkfuiMUIYuzFIcdnVa8Bn1zvZ4Uurc&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=FztSyO9IdR2ly2Cwmu1RhMdXDKw1epjGp_4pel_o_pg&s=YwxW95s5oIBrBLkfuiMUIYuzFIcdnVa8Bn1zvZ4Uurc&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=FztSyO9IdR2ly2Cwmu1RhMdXDKw1epjGp_4pel_o_pg&s=YwxW95s5oIBrBLkfuiMUIYuzFIcdnVa8Bn1zvZ4Uurc&e=>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 2 Aug 2017 19:54:22 +0000

Phil,

Can you be more specific about which items have been discussed and what the consensus was? Items 2 and 4 touch on the issuer mismatch matter, but are about clarifying requirements for profiling specifications and so far as I can tell are aligned with the intentions of the current text regarding the handling and interpretation of the “sub” and “iss” claims. Similarly item 6 addresses a profiling specification requirement related to the JWT confusion issue, and does not deviate from the WG consensus as I understand it.

Item 1, I should hope, is uncontroversial. ☺

From: Id-event <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Date: Wednesday, August 2, 2017 at 12:22 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: SecEvent <[email-masked]>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

Annabelle,

Phil

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

On Aug 2, 2017, at 11:43 AM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

  1.  Note regarding Subject Issuer vs. SET Issuer
The note regarding the potential for Subject and SET Issuer mismatch (in the “iss” definition in section 1.2) is I think more prescriptive than intended. As written, it mandates placing the Subject’s Issuer in an “iss” value within the event payload, but does not define a format or structure for this value. The logical format – that of the “iss” JWT claim – may or may not be appropriate, depending on the nature of the event and its Subject. I suggest removing this note and covering this concern elsewhere (see #4 below, re: Subject Identification).

  2.  Explicit Typing of SETs
I suggest removing the text “if the SET could be used in an application context in which it could be confused with other kinds of JWTs” from the first paragraph of section 2.2, making the secevent+jwt typ header mandatory to implement for all SETs. This conditional is impossible to evaluate, as new types of JWTs will be introduced over time. Just considering existing JWTs, it is a lot to ask for Profiling Spec authors to fully examine the contents and usage of every existing JWT. Mandating use of typ for SETs takes this load off of Profiling Spec authors and insures that future specs have a consistent, reliable way to defend against JWT type confusion.

  3.  Requirements for SET Profiles: Subject Identification
I suggest adding text along the lines of “Profiling Specifications MUST define for each of their events how the Subject is identified in the SET, as well as how to address conflicts the event Subject’s Issuer and the SET Issuer if applicable. It is NOT RECOMMENDED for Profiling Specifications to use the “sub” claim in cases where the Subject is not globally unique and has a different Issuer from the SET itself.”

  4.  Guidance for Signing SETs
The text in the last paragraph of section 4.1 is unclear to me. It seems to suggest that it is safe to send unsigned JWTs over a channel that lacks transport-layer security, so long as requests include a bearer token or use Basic Authentication. Am I misreading this? It seems counter to the guidance given earlier in the same section.

  5.  Distinguishing SETs from other kinds of JWTs
The last sentence of the first paragraph of section 4.7 seems impossible to me. Profiling Specifications cannot be solely responsible for ensuring incompatibility with all future JWT profiles. They can at best ensure incompatibility with existing JWT profiles and be compatible with a standard mechanism by which future JWT profiles may ensure incompatibility (e.g. the “secevent+jwt” typ header). It may be enough to strike the “(or other)” text from this sentence.

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of "M.Lizar@OCG" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 1, 2017 at 9:17 AM
To: Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

+1 on existing text .

- Mark

                                                                -- Mike

This is to announce working group last call on this draft (https://datatracker.ietf.org/doc/draft-ietf-secevent-token/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dsecevent-2Dtoken_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=FztSyO9IdR2ly2Cwmu1RhMdXDKw1epjGp_4pel_o_pg&s=NcFFmLZ6aFDT27EoSTD7rkP2m2nktWqgSd3_CPep8Uw&e=>).

Thanks,
    Dick and Yaron
_______________________________________________
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=FztSyO9IdR2ly2Cwmu1RhMdXDKw1epjGp_4pel_o_pg&s=YwxW95s5oIBrBLkfuiMUIYuzFIcdnVa8Bn1zvZ4Uurc&e=>

_______________________________________________
Id-event 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=FztSyO9IdR2ly2Cwmu1RhMdXDKw1epjGp_4pel_o_pg&s=YwxW95s5oIBrBLkfuiMUIYuzFIcdnVa8Bn1zvZ4Uurc&e=

---

From: Phil Hunt <[email-masked]>
Date: Wed, 2 Aug 2017 13:07:43 -0700

Annabelle,

You are correct #1 isn’t really controversial.

I would look at the minutes of Chicago (see Mike’s presentation) and then the intervening discussing prior to Prague.

I’ve made my concerns clear so I won’t bother repeating them. Your comments suggest some remaining disagreement on what should be in the common SET Token spec vs down stream event profiles. E.g. some have expressed that SET’s job is simply to define the event claim and nothing more.

Phil

> On Aug 2, 2017, at 12:54 PM, Richard Backman, Annabelle <[email-masked]> wrote:
> 
> Phil,
>  
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dr8DHRQ7TCuwn3QgnXZDcyuP9gE-wrdKUmrJ-MSlw5g&s=GVYabcbdptKpdVyAGGSN7wwhQaoUuIbYv3g0_vTWp4o&e=>
> [email-masked] <mailto:[email-masked]>
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 2 Aug 2017 21:17:39 +0000

Let me restate the iss/sub related items, starting with item 2…

Consider a hypothetical profiling specification where the subject’s issuer is always the audience for the token (e.g. an RP sending events back to an IdP, using the IdP’s own subject identifiers). The draft as written prohibits the profiling specification from simply stating “the subject issuer is the value of the aud claim” and requires that it instead duplicate the aud value in an “iss” attribute in its event payloads. I don’t recall this being the consensus.

Item 4 is an attempt to insure that how the subject for any given event is represented in the token is defined *somewhere*. Feel free to ignore the 2nd sentence of my suggested text (“It is NOT RECOMMENDED for Profiling Specifications…”) if there is disagreement on that recommendation; it’s the first sentence that’s important. As it stands, the draft defines Subject in section 1.2, but makes no comment on how Subject is represented aside from that it might be in the sub claim, and profiling specifications that use sub should declare semantics. My suggestion is to require that profile specifications declare how they represent the subject of their events, however they choose to do it.

From: Phil Hunt <[email-masked]>
Date: Wednesday, August 2, 2017 at 1:07 PM
To: "Richard Backman, Annabelle" <[email-masked]>
Cc: SecEvent <[email-masked]>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

Annabelle,

Phil

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

On Aug 2, 2017, at 12:54 PM, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

Phil,

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 2, 2017 at 12:22 PM
To: "Richard Backman, Annabelle" <[email-masked]<mailto:[email-masked]>>
Cc: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] WG Last Call for draft-ietf-secevent-token-02

Annabelle,

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com_&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=dr8DHRQ7TCuwn3QgnXZDcyuP9gE-wrdKUmrJ-MSlw5g&s=GVYabcbdptKpdVyAGGSN7wwhQaoUuIbYv3g0_vTWp4o&e=>
[email-masked]<mailto:[email-masked]>

+1 on existing text .

- Mark

                                                                -- Mike

Thanks,
    Dick and Yaron

---

From: Marius Scurtescu <[email-masked]>
Date: Wed, 2 Aug 2017 14:45:41 -0700

The abstract mentions "issuer" and "receiver" in the last sentence.
"receiver" does not sound right (that should be used in the context of a
transmitter), but I don't have a better suggestion. Audience?

The last paragraph of section 1 mentions "subscriber". I think it should be
either "receiver" or "audience".

The explanation for figure 1 states that the issuer denotes the
transmitter. If the issuer and the transmitter are assumed to be the same
entity, then the transmitter definition in section 1.2 should make that
clear.

Figure 3, I think the "sub" claim should be nested in the event, next to
the issuer that provides the correct context. The "iss" and "sub"
definitions in 2.1 also touch on this, providing conflicting advice.

Section 2,1, definition of "nbf". The definition says that this is the
event time. I see two problems:
- the name suggest "not before", not exactly the same as event time
- there can be multiple events
maybe this claim should be dropped?

Section 2.1, definition of "exp". Omitting this claim is the short term
solution to the confusion issue. Why not mention that and that it SHOULD
NOT be used?

Section 2.1, definition of "events". It states that all events must refer
to the same logical event. Lately in discussions we reached the conclusion
that all events in a SET should be defined in the same profile, which is a
stronger requirement. I think this definition should mention that.

Regarding events and profiles. There was a proposal to add a new claim to
uniquely identify the profile. I think we need to discuss that.

Figure 5. Maybe a signed example would be better, especially that the next
paragraph mentions that signatures or encryption should be used.

Section 4.5, second paragraph. Mentions that "nonce" is also required, but
that is not actually true. Id Tokens issued at the token endpoint for
example will not have it. I suggest we drop the whole paragraph.

Marius

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 3 Aug 2017 17:03:18 +0200

Hello,

to me, the "audience" claim seems to be a good choice here.

Viele Grüße,

Henk

On 08/02/2017 11:45 PM, Marius Scurtescu wrote:
> The last paragraph of section 1 mentions "subscriber". I think it should 
> be either "receiver" or "audience".
> 
> transmitter. If the issuer and the transmitter are assumed to be the 
> same entity, then the transmitter definition in section 1.2 should make 
> that clear.
> 
> Section 2.1, definition of "events". It states that all events must 
> refer to the same logical event. Lately in discussions we reached the 
> conclusion that all events in a SET should be defined in the same 
> profile, which is a stronger requirement. I think this definition should 
> mention that.
> 
> Regarding events and profiles. There was a proposal to add a new claim 
> to uniquely identify the profile. I think we need to discuss that.
> 
> Figure 5. Maybe a signed example would be better, especially that the 
> next paragraph mentions that signatures or encryption should be used.
> 
> Section 4.5, second paragraph. Mentions that "nonce" is also required, 
> but that is not actually true. Id Tokens issued at the token endpoint 
> for example will not have it. I suggest we drop the whole paragraph.
> 
> 
> Marius
> 
> On Mon, Jul 31, 2017 at 1:40 PM, Yaron Sheffer <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     This is to announce working group last call on this draft
>     (https://datatracker.ietf.org/doc/draft-ietf-secevent-token/
>     <https://datatracker.ietf.org/doc/draft-ietf-secevent-token/>).
> 
>     Please send your comments to the list. Even if you are perfectly
>     happy with the draft, please let us know that you support its
>     publication as-is by posting to the list.
> 
>     <https://www.ietf.org/mailman/listinfo/id-event>
> 
> 
> 
>