Subject: [Id-event] Heads-up about SET spec updates

From: Mike Jones <[email-masked]>
Date: Thu, 29 Jun 2017 00:08:23 +0000

Hi folks,

I wanted to give you a heads-up about two SET spec updates in the current editor's draft before they are published.

The first solves the potential ID Token / SET confusion problem by requiring that SETs not include a top-level "exp" claim when ID Tokens could also be generated by the same issuer.  Because "exp" is a required ID Token claim, SETs would therefore be rejected by existing ID Token validation code.  Note that this solution is already recommended in the specification.  The editor's draft update makes this solution mandatory.  This provides a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discussion since.

The second adds the following new section:

Requirements for SET Profiles<file:///C:/mbj/DSG/JSON%20Specs/draft-ietf-secevent-token.html#Profiles>

Profile Specifications for SETs define the syntax and semantics of SETs conforming to that SET profile and rules for validating those SETs. The syntax defined by profiling specifications includes what claims and event payload values are used by SETs utilizing the profile.

Defining the semantics of the SET contents for SETs utilizing the profile is equally important. Possibly most important is defining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used for cryptographic operations used in the JWT representing the SET. For instance, some profiles may define an algorithm for retrieving the SET issuer's keys that uses the iss claim value as its input.

Profile Specifications MUST clearly specify the steps that a recipient of a SET utilizing that profile MUST perform to validate that the SET is both syntactically and semantically valid.

It's included to inform profile writers about what they must do to be able to use SETs securely.  While much of the discussion as of late has been about syntax, semantics is equally important, and must be considered by profile writers and deployers.

I believe that the new section contains only statements that are already factually accurate requirements but that were previously unstated.  The editor's draft makes these requirements explicit.  Feedback on how to make these requirements even more clear, is of course, welcomed.

                                                                Best wishes,
                                                                -- Mike

---

From: William Denniss <[email-masked]>
Date: Wed, 28 Jun 2017 17:24:18 -0700

Thank you Mike for working on this. I'm very happy with the change
regarding the "exp" claim, and believe it is the best resolution to the "ID
Token" confusion concern.

By making the "exp" claim that is already
<https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1> NOT
RECOMMENDED in the current draft a MUST NOT, we can provide the ID Tokens
and SET uniqueness guarantee that is desired, allowing these two types of
JWTs to be used with a common issuer. This also allows "sub" to be used for
its intended purpose (as defined by RFC7519) without modification, which
other working groups that wish to profile SET have expressed an interest to
do

The benefit the community will gain from the SET standard overall is a
standard way to express events that won't conflict with ID Token (no "iss"
partitioning required). With Mike's changes we achieve that, and in a way
that retains the original simplicity, extensibility and generalizability
goals of SET by not redefining any of JWT's standard claims.

On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones <[email-masked]>
wrote:

> Hi folks,
>
>
>
> I wanted to give you a heads-up about two SET spec updates in the current
> editor’s draft before they are published.
>
>
>
> The first solves the potential ID Token / SET confusion problem by
> requiring that SETs not include a top-level “exp” claim when ID Tokens
> could also be generated by the same issuer.  Because “exp” is a required ID
> Token claim, SETs would therefore be rejected by existing ID Token
> validation code.  Note that this solution is already recommended in the
> specification.  The editor’s draft update makes this solution mandatory.
> This provides a simple and durable solution to the problem we agreed to
> solve at IETF 98 in Chicago and that has been the subject of much
> discussion since.
>
>
>
> Requirements for SET Profiles
>
>
>
> Profile Specifications for SETs define the syntax and semantics of SETs
> conforming to that SET profile and rules for validating those SETs. The
> syntax defined by profiling specifications includes what claims and event
> payload values are used by SETs utilizing the profile.
>
>
>
> Defining the semantics of the SET contents for SETs utilizing the profile
> is equally important. Possibly most important is defining the procedures
> used to validate the SET issuer and to obtain the keys controlled by the
> issuer that were used for cryptographic operations used in the JWT
> representing the SET. For instance, some profiles may define an algorithm
> for retrieving the SET issuer's keys that uses the iss claim value as its
> input.
>
>
>
> Profile Specifications MUST clearly specify the steps that a recipient of
> a SET utilizing that profile MUST perform to validate that the SET is both
> syntactically and semantically valid.
>
>
>
> It’s included to inform profile writers about what they must do to be able
> to use SETs securely.  While much of the discussion as of late has been
> about syntax, semantics is equally important, and must be considered by
> profile writers and deployers.
>
>
>
> I believe that the new section contains only statements that are already
> factually accurate requirements but that were previously unstated.  The
> editor’s draft makes these requirements explicit.  Feedback on how to make
> these requirements even more clear, is of course, welcomed.
>
>
>
>                                                                 Best
> wishes,
>
>                                                                 -- Mike
>
>
>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Wed, 28 Jun 2017 17:38:45 -0700

I agree on the exp part. 

Regarding the second part. I would like to see more discussion. 

For example, in the the use cases, there may be compatibility issues if different set profiles cannot be sent over the same stream. 

Such profiles should avoid things like requiring signing and encryption without consideration regarding how they are transferred.  Also key management might be better tied up in how the streams are manages because the network relationship may define the requirements rather than the data. 

My initial reaction is, the profiles should stick to the data and valid interpretation. 

If the group agrees I will merge the exp and post over the weekend. 

I can merge the second part if there is a strong agreement to do so. 

Thanks!

Phil

> On Jun 28, 2017, at 5:24 PM, William Denniss <[email-masked]> wrote:
> 
> Thank you Mike for working on this. I'm very happy with the change regarding the "exp" claim, and believe it is the best resolution to the "ID Token" confusion concern.
> 
> By making the "exp" claim that is already NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID Tokens and SET uniqueness guarantee that is desired, allowing these two types of JWTs to be used with a common issuer. This also allows "sub" to be used for its intended purpose (as defined by RFC7519) without modification, which other working groups that wish to profile SET have expressed an interest to do
> 
> The benefit the community will gain from the SET standard overall is a standard way to express events that won't conflict with ID Token (no "iss" partitioning required). With Mike's changes we achieve that, and in a way that retains the original simplicity, extensibility and generalizability goals of SET by not redefining any of JWT's standard claims.
> 
> 
>> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones <[email-masked]> wrote:
>> Hi folks,
>> 
>>  
>> 
>> I wanted to give you a heads-up about two SET spec updates in the current editor’s draft before they are published.
>> 
>>  
>> 
>> The first solves the potential ID Token / SET confusion problem by requiring that SETs not include a top-level “exp” claim when ID Tokens could also be generated by the same issuer.  Because “exp” is a required ID Token claim, SETs would therefore be rejected by existing ID Token validation code.  Note that this solution is already recommended in the specification.  The editor’s draft update makes this solution mandatory.  This provides a simple and durable solution to the problem we agreed to solve at IETF 98 in Chicago and that has been the subject of much discussion since.
>> 
>>  
>> 
>> It’s included to inform profile writers about what they must do to be able to use SETs securely.  While much of the discussion as of late has been about syntax, semantics is equally important, and must be considered by profile writers and deployers.
>> 
>>  
>> 
>> I believe that the new section contains only statements that are already factually accurate requirements but that were previously unstated.  The editor’s draft makes these requirements explicit.  Feedback on how to make these requirements even more clear, is of course, welcomed.
>> 
>>  
>> 
>>                                                                 Best wishes,
>> 
>>                                                                 -- Mike
>> 
>>  
>> 
> 
> _______________________________________________
> 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=_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=

---

From: John Bradley <[email-masked]>
Date: Thu, 29 Jun 2017 13:37:04 -0400

I agree on exp.

I think defining trust relationships should be in the profiles as they may be quite different.

That is why mixing events in the same message will be a problem.  I thought we agreed on that.

Trying to define a fixed trust relationship for the transport is likely going to cause people to roll there own.

Even in Connect for specific verticals like finance we see diffrences in registration etc to reflect the need to accommodate eIDS and other regulations.

One size fits all is great if you are the one size.  

I do think we should encourage people to use JWKS URI discovers from issuer meta-data based on the issuers well-known as a pattern that has proven to be repeatable. 

It would be nice if we had those specs done in the IETF:)

John B.

> On Jun 28, 2017, at 8:38 PM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> I agree on the exp part. 
> 
> On Jun 28, 2017, at 5:24 PM, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> By making the "exp" claim that is already <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=_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=5L9qqH_evklX-HjDF8KkZ2e5bNa6fZc3kJIXL2qfUWs&e=> NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID Tokens and SET uniqueness guarantee that is desired, allowing these two types of JWTs to be used with a common issuer. This also allows "sub" to be used for its intended purpose (as defined by RFC7519) without modification, which other working groups that wish to profile SET have expressed an interest to do
>> 
>> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi folks,
>> 
>>  
>> 
>> Requirements for SET Profiles <>
>>  
>> [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=_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&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=_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>

---

From: "M.Lizar@OCG" <[email-masked]>
Date: Thu, 29 Jun 2017 18:45:29 +0100

+1 

Thanks for you work on this and support both these changes. 

- Mark

> On 29 Jun 2017, at 01:24, William Denniss <[email-masked]> wrote:
> 
> By making the "exp" claim that is already <https://tools.ietf.org/html/draft-ietf-secevent-token-01#section-2.1> NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID Tokens and SET uniqueness guarantee that is desired, allowing these two types of JWTs to be used with a common issuer. This also allows "sub" to be used for its intended purpose (as defined by RFC7519) without modification, which other working groups that wish to profile SET have expressed an interest to do
> 
> https://www.ietf.org/mailman/listinfo/id-event

---

From: Mike Jones <[email-masked]>
Date: Thu, 29 Jun 2017 17:50:58 +0000

Thanks, John.

The good news about key metadata in the IETF is that we’re nearly done with standardizing the jwks_uri pattern in the IETF, per https://tools.ietf.org/html/draft-ietf-oauth-discovery-06#section-2.  (It’s currently waiting for the AD write-up from EKR.)

Phil, I believe that all the statements in the new “Requirements for SET Profiles” section are demonstrably true and add no new requirements.  They are there to make requirements that were already implicit explicit.  Phil, if you believe that any of the sentences in the section are false, please call them out explicitly and say why they’re false.  If one or more of them are false, I’ll obviously clarify or redact those, while leaving the rest in place as guidance to users of the spec.

I’ll point out that even if a profile decided to delegate its key management to a transport, as you’re advocating, Phil, the profile would still need to explicitly say that.  It wouldn’t be a complete or usable profile if it didn’t define how to retrieve the keys used to validate the JWT.  So your proposal is one way of a profile satisfying the requirement “Possibly most important is defining the procedures used to validate the SET issuer and to obtain the keys controlled by the issuer that were used for cryptographic operations used in the JWT representing the SET.”  Given that your proposal is a way to satisfy this requirement, I don’t see any grounds for you to oppose it.  In fact, I believe it argues that you should support it.

Saying nothing about the semantic requirements is doing no one any favors.

                                                                Thanks all,
                                                                -- Mike

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, June 29, 2017 10:37 AM
To: Phil Hunt (IDM) <[email-masked]>
Cc: William Denniss <[email-masked]>; Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Heads-up about SET spec updates

I agree on exp.

John B.

On Jun 28, 2017, at 8:38 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:

I agree on the exp part.

Thanks!

Phil

On Jun 28, 2017, at 5:24 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Mike for working on this. I'm very happy with the change regarding the "exp" claim, and believe it is the best resolution to the "ID Token" confusion concern.

By making the "exp" claim that is already<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=_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=5L9qqH_evklX-HjDF8KkZ2e5bNa6fZc3kJIXL2qfUWs&e=> NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID Tokens and SET uniqueness guarantee that is desired, allowing these two types of JWTs to be used with a common issuer. This also allows "sub" to be used for its intended purpose (as defined by RFC7519) without modification, which other working groups that wish to profile SET have expressed an interest to do

On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Hi folks,

                                                                Best wishes,
                                                                -- Mike

_______________________________________________
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=_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=
_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 29 Jun 2017 11:02:33 -0700

+1 for exp

If we allow only one profile per SET then maybe we need a profile URI and
this URI should be present as a top level claim? Or even adding the profile
URI to the JWT header?

Having to fully parse the SET to infer the profile based on event types
only to very the signature does not sound right. Also, mapping from event
type URIs to profiles is not clear. Imagine a receiver that accepts events
(it must validate at least syntax and signatures) then further distributes
them based on either audience or event type. You don't want to update this
receiver every single time a profile adds a new event type.

Another potential solution for key location is to have the transmitter
explicitly publish it, as mentioned in another email thread.

We still have one open issue: SET issuer vs sub context issuer. Asking
profiles to deal with this does not sound safe nor enough to me.

Marius

On Thu, Jun 29, 2017 at 10:37 AM, John Bradley <[email-masked]> wrote:

> Even in Connect for specific verticals like finance we see diffrences in
> registration etc to reflect the need to accommodate eIDS and other
> regulations.
>
> I do think we should encourage people to use JWKS URI discovers from
> issuer meta-data based on the issuers well-known as a pattern that has
> proven to be repeatable.
>
> For example, in the the use cases, there may be compatibility issues if
> different set profiles cannot be sent over the same stream.
>
> Such profiles should avoid things like requiring signing and encryption
> without consideration regarding how they are transferred.  Also key
> management might be better tied up in how the streams are manages because
> the network relationship may define the requirements rather than the data.
>
> <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=_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH0&s=5L9qqH_evklX-HjDF8KkZ2e5bNa6fZc3kJIXL2qfUWs&e=>
>  NOT RECOMMENDED in the current draft a MUST NOT, we can provide the ID
> Tokens and SET uniqueness guarantee that is desired, allowing these two
> types of JWTs to be used with a common issuer. This also allows "sub" to be
> used for its intended purpose (as defined by RFC7519) without modification,
> which other working groups that wish to profile SET have expressed an
> interest to do
>
>> for retrieving the SET issuer's keys that uses the iss claim value as
>> its input.
>>
>>
>>
>> It’s included to inform profile writers about what they must do to be
>> able to use SETs securely.  While much of the discussion as of late has
>> been about syntax, semantics is equally important, and must be considered
>> by profile writers and deployers.
>>
>>
>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=
> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=_XF994zVn1_AeS-
> CzStqOQaVQpsdjjvfBy35S0o7tH0&s=3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-
> nFaqUxKQ&e=
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 29 Jun 2017 11:27:18 -0700

A SET Profile is just a data message that describes something that occurred.  Nothing more.

IMO The trust relationship should not be part of the data profile.

Maybe the trust profile is a separate document?  But right now it seems better suited to the Stream systems assuming there are a relatively limited number of trust relationships.

The composition that you propose I believe leads us down the road to a combinations and permutations problem that will be un-implementable in practice because every implementer has to implement every trust profile, every set token format and every transfer method.

I think this issue is foundational.  Going the wrong way completely undermines the value of having SETEVENTs.  We might as well each go our own way using JWT only.

Phil

Oracle Corporation, Identity Cloud Services Architect & Standards
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Jun 29, 2017, at 10:50 AM, Mike Jones <[email-masked]> wrote:
> 
> Thanks, John.
>  
> The good news about key metadata in the IETF is that we’re nearly done with standardizing the jwks_uri pattern in the IETF, per https://tools.ietf.org/html/draft-ietf-oauth-discovery-06#section-2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Doauth-2Ddiscovery-2D06-23section-2D2&d=DwMGaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=71IomwJu9KQH3fBWBt8nHYVE3hpaH3anjMx9qFoBNTg&s=zKoyTqrkKrUrPYiKYVikjBwu5wlXy5un9Tsw-iSwQpI&e=>.  (It’s currently waiting for the AD write-up from EKR.)
>  
> On Jun 28, 2017, at 8:38 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
>  
> I agree on the exp part. 
>  
> 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=71IomwJu9KQH3fBWBt8nHYVE3hpaH3anjMx9qFoBNTg&s=Sdby2JoU1lYPBaU7-lO5C75RzeeuhWAyvZ8NZ0Lvgbk&e=>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 29 Jun 2017 12:25:07 -0700

Hi Phil

wrt asking for more discussion, I appreciate you making the suggestion on
behalf of the chairs. It does seem there is a reasonable amount of
discussion going on now would you not agree?

I'd like to get the doc updated in time for Prague so that we have a clear
reference point for discussion there and then.

Unclear why you would post a change when it was Mike that did this work. Am
I missing something?

Mike: would you update the doc with what you think is rough consensus when
you have time so that we can have a crisp discussion in Prague?

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

---

From: Phil Hunt <[email-masked]>
Date: Thu, 29 Jun 2017 12:57:56 -0700

Dick,

The section is a brand new section. It seems to me that has not been any (or limited) discussion to warrant putting it in the document.  It certainly came to me as a surprise.

I think the issue of trust model needs to be discussed.  It may not belong here at all.

Please advise.  Do you want it posted in spite of consensus?

Phil

> On Jun 29, 2017, at 12:25 PM, Dick Hardt <[email-masked]> wrote:
> 
> Hi Phil
> 
> wrt asking for more discussion, I appreciate you making the suggestion on behalf of the chairs. It does seem there is a reasonable amount of discussion going on now would you not agree?
> 
> I'd like to get the doc updated in time for Prague so that we have a clear reference point for discussion there and then.
> 
> Unclear why you would post a change when it was Mike that did this work. Am I missing something?
> 
> Mike: would you update the doc with what you think is rough consensus when you have time so that we can have a crisp discussion in Prague?
> 
> 
> 
> On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> I agree on the exp part. 
> 
> 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=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=>
> 
> 
> 
> 
> -- 
> Subscribe to the HARDTWARE <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3Ud1v2pGXDw45g9FkmIwtWo45zdFG_NSgcjcf6kHnEw&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=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=

---

From: Dick Hardt <[email-masked]>
Date: Thu, 29 Jun 2017 20:51:00 +0000

I understand it is new and that there is contention.

We clearly want consensus for us to be done with the draft. I think having
it in the next draft anchors the discussion so we can discuss and arrive at
consensus or an alternative.

So yes, is like a new draft posted so we can discuss.

On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt <[email-masked]> wrote:

> Dick,
>
> The section is a brand new section. It seems to me that has not been any
> (or limited) discussion to warrant putting it in the document.  It
> certainly came to me as a surprise.
>
> www.independentid.com
> [email-masked]
>>> I wanted to give you a heads-up about two SET spec updates in the
>>> current editor’s draft before they are published.
>>>
>>>
>>>
>>> Defining the semantics of the SET contents for SETs utilizing the
>>> profile is equally important. Possibly most important is defining the
>>> procedures used to validate the SET issuer and to obtain the keys
>>> controlled by the issuer that were used for cryptographic operations used
>>> in the JWT representing the SET. For instance, some profiles may define an
>>> algorithm for retrieving the SET issuer's keys that uses the iss claim
>>> value as its input.
>>>
>>>
>>>
>>> Profile Specifications MUST clearly specify the steps that a recipient
>>> of a SET utilizing that profile MUST perform to validate that the SET is
>>> both syntactically and semantically valid.
>>>
>>>
>>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=>
>>
>>
>
>
> --
> Subscribe to the HARDTWARE
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3Ud1v2pGXDw45g9FkmIwtWo45zdFG_NSgcjcf6kHnEw&e=>
> mail list to learn about projects I am working on!

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 29 Jun 2017 15:04:35 -0700

Ok. 

I spoke with Mike and he will post his changes to SET in a new revision over the weekend. 

Phil

> On Jun 29, 2017, at 1:51 PM, Dick Hardt <[email-masked]> wrote:
> 
> We clearly want consensus for us to be done with the draft. I think having it in the next draft anchors the discussion so we can discuss and arrive at consensus or an alternative. 
> 
>>>> On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) <[email-masked]> wrote:
>>>> I agree on the exp part. 
>>>> 
>>> Subscribe to the HARDTWARE mail list to learn about projects I am working on!
> Subscribe to the HARDTWARE mail list to learn about projects I am working on!

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 30 Jun 2017 00:01:14 +0000

Sorry for a tardy reply, but +1 for the both changes. 'exp' claim
requirement is a good practical step with a backward compatibility.
Having said that, I believe inferring message types from the
existence/absence of a claim is not a good security practice. I would like
to see an explicit typing through "typ" claim added as well.

Nat

On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) <[email-masked]>
wrote:

>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Dzhv_1aTAhzsyQq1UpCO7qiWxzAHJX8y-_VGJC3EACg&s=fEVvFsEqkTmCpY6sIa_GV_S3Gy1gxhG56Wabw24G0LA&e=>
>> [email-masked]
>>
>> I'd like to get the doc updated in time for Prague so that we have a
>> clear reference point for discussion there and then.
>>
>> Mike: would you update the doc with what you think is rough consensus
>> when you have time so that we can have a crisp discussion in Prague?
>>
>>
>>
>>> On Wed, Jun 28, 2017 at 5:08 PM, Mike Jones <[email-masked]
>>> > wrote:
>>>
>>>> Hi folks,
>>>>
>>>>
>>>>
>>>> I believe that the new section contains only statements that are
>>>> already factually accurate requirements but that were previously unstated.
>>>> The editor’s draft makes these requirements explicit.  Feedback on how to
>>>> make these requirements even more clear, is of course, welcomed.
>>>>
>>>>
>>>>
>>>>                                                                 Best
>>>> wishes,
>>>>
>>>>                                                                 -- Mike
>>>>
>>>>
>>>>
>>>
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Dzhv_1aTAhzsyQq1UpCO7qiWxzAHJX8y-_VGJC3EACg&s=fK8RXn01aixoYsClkkudgJGExH0ddv6Cv3KXFY4PtC0&e=>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Dick Hardt <[email-masked]>
Date: Thu, 29 Jun 2017 17:05:13 -0700

<individual hat?

+1 to typ claim.

On Thu, Jun 29, 2017 at 5:01 PM, Nat Sakimura <[email-masked]> wrote:

>> We clearly want consensus for us to be done with the draft. I think
>> having it in the next draft anchors the discussion so we can discuss and
>> arrive at consensus or an alternative.
>>
>>> wrt asking for more discussion, I appreciate you making the suggestion
>>> on behalf of the chairs. It does seem there is a reasonable amount of
>>>>> Profile Specifications for SETs define the syntax and semantics of
>>>>> SETs conforming to that SET profile and rules for validating those SETs.
>>>>> The syntax defined by profiling specifications includes what claims and
>>>>> event payload values are used by SETs utilizing the profile.
>>>>>
>>>>>
>>>>>
>>>>> algorithm for retrieving the SET issuer's keys that uses the iss
>>>>> claim value as its input.
>>>>>
>>>>>
>>>>>
>>>>> Mike
>>> JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=
>>> ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=
>>> lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=
>>>
>>>
>>> --

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Thu, 29 Jun 2017 17:17:57 -0700

+1 to typ claim. 

Phil

> On Jun 29, 2017, at 5:01 PM, Nat Sakimura <[email-masked]> wrote:
> 
> Sorry for a tardy reply, but +1 for the both changes. 'exp' claim requirement is a good practical step with a backward compatibility. 
> Having said that, I believe inferring message types from the existence/absence of a claim is not a good security practice. I would like to see an explicit typing through "typ" claim added as well. 
> 
> Nat
> 
>> On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) <[email-masked]> wrote:
>> Ok. 
>>

---

From: William Denniss <[email-masked]>
Date: Fri, 30 Jun 2017 09:33:22 -0700

+1 to typ.

So "typ": "set" or "typ": "event"?

On Thu, Jun 29, 2017 at 5:17 PM, Phil Hunt (IDM) <[email-masked]>
wrote:

>>>> 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=_XF994zVn1_AeS-CzStqOQaVQpsdjjvfBy35S0o7tH
>>>> 0&s=3s1GCc-3g2KU_pN6HvWVHgWBJXs6OGPY8K-nFaqUxKQ&e=
>>>>
>>>>
>>> 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=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-
>>> 02wy3p45oXGQ&s=lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&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=lFi9x3XzhB1OHwhVnmH2aridW1-w1TTcHB2HmekcrjM&s=ld0li4dqaj6S8muGsxpBcHBcY1PlyLBLJ-TcyErqz08&e=>
>>
> --
>
> Nat Sakimura
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 30 Jun 2017 16:56:34 +0000

There had already been discussions, both in Chicago, and in the JWT BCP context, that if we were going to use a type identifier, we would use the existing “typ” header parameter and not create a new claim.  This is a MIME type, with the ability to omit “application/” for space reasons, if desired.

Since there appears to be broad interest in having the ability to use explicit typing of the SET, I will plan to define the “application/secevent+jwt” MIME type in the SET draft before publishing.  SETs could then include the “typ”:“secevent+jwt” header parameter value to provide explicit typing.  Unless I hear objections soon, I will proceed on this basis.

                                                       -- Mike

From: William Denniss [mailto:[email-masked]]
Sent: Friday, June 30, 2017 9:33 AM
To: Phil Hunt (IDM) <[email-masked]>
Cc: Nat Sakimura <[email-masked]>; Dick Hardt <[email-masked]>; Mike Jones <[email-masked]>; [email-masked]
Subject: Re: [Id-event] Heads-up about SET spec updates

+1 to typ.

On Thu, Jun 29, 2017 at 5:17 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
+1 to typ claim.

Phil

On Jun 29, 2017, at 5:01 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
Sorry for a tardy reply, but +1 for the both changes. 'exp' claim requirement is a good practical step with a backward compatibility.
Having said that, I believe inferring message types from the existence/absence of a claim is not a good security practice. I would like to see an explicit typing through "typ" claim added as well.

Nat

On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
Ok.

Phil

On Jun 29, 2017, at 1:51 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
I understand it is new and that there is contention.

On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Dick,

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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Dzhv_1aTAhzsyQq1UpCO7qiWxzAHJX8y-_VGJC3EACg&s=fEVvFsEqkTmCpY6sIa_GV_S3Gy1gxhG56Wabw24G0LA&e=>
[email-masked]<mailto:[email-masked]>

On Jun 29, 2017, at 12:25 PM, Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Phil

On Wed, Jun 28, 2017 at 5:38 PM, Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>> wrote:
I agree on the exp part.

Thanks!

Phil

                                                                Best wishes,
                                                                -- Mike

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=>

--
Subscribe to the HARDTWARE<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=3Ud1v2pGXDw45g9FkmIwtWo45zdFG_NSgcjcf6kHnEw&e=> mail list to learn about projects I am working on!
_______________________________________________
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=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=

--
Subscribe to the HARDTWARE<https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Dzhv_1aTAhzsyQq1UpCO7qiWxzAHJX8y-_VGJC3EACg&s=fK8RXn01aixoYsClkkudgJGExH0ddv6Cv3KXFY4PtC0&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=lFi9x3XzhB1OHwhVnmH2aridW1-w1TTcHB2HmekcrjM&s=ld0li4dqaj6S8muGsxpBcHBcY1PlyLBLJ-TcyErqz08&e=>
--

Nat Sakimura

---

From: Justin Richer <[email-masked]>
Date: Fri, 30 Jun 2017 17:05:25 -0400

Unless there’s an encoding for security events other than JWT, wouldn’t application/secevent suffice?

 — Justin

> On Jun 30, 2017, at 12:56 PM, Mike Jones <[email-masked]> wrote:
> 
>   <>
> On Thu, Jun 29, 2017 at 5:17 PM, Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> +1 to typ claim. 
> 
> Phil
> 
> On Jun 29, 2017, at 5:01 PM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Fri, Jun 30, 2017 at 7:04 AM Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>> wrote:
> Ok. 
>  
> On Jun 29, 2017, at 1:51 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Thu, Jun 29, 2017 at 12:58 PM Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> Dick,
>  
> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Dzhv_1aTAhzsyQq1UpCO7qiWxzAHJX8y-_VGJC3EACg&s=fEVvFsEqkTmCpY6sIa_GV_S3Gy1gxhG56Wabw24G0LA&e=>
> [email-masked] <mailto:[email-masked]>
>  
> On Jun 29, 2017, at 12:25 PM, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi 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=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&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=ETbGIxRZLcQfYZtYUVk6T7HkwYGfXx-02wy3p45oXGQ&s=lMSowbDnjUeXE7zLprGHSPRgxZMhEZuIqTkLTfgBNGE&e=>
>  
> -- 
> Subscribe to the HARDTWARE <https://urldefense.proofpoint.com/v2/url?u=http-3A__hardtware.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=Dzhv_1aTAhzsyQq1UpCO7qiWxzAHJX8y-_VGJC3EACg&s=fK8RXn01aixoYsClkkudgJGExH0ddv6Cv3KXFY4PtC0&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=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=lFi9x3XzhB1OHwhVnmH2aridW1-w1TTcHB2HmekcrjM&s=ld0li4dqaj6S8muGsxpBcHBcY1PlyLBLJ-TcyErqz08&e=>
> -- 
> Nat Sakimura
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 30 Jun 2017 21:07:41 +0000

There may be a SAML encoding in the works.

                                                                -- Mike

From: Justin Richer [mailto:[email-masked]]
Sent: Friday, June 30, 2017 2:05 PM
To: Mike Jones <[email-masked]>
Cc: William Denniss <[email-masked]>; Phil Hunt <[email-masked]>; Nat Sakimura <[email-masked]>; [email-masked]; Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Heads-up about SET spec updates

 — Justin

On Jun 30, 2017, at 12:56 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                       -- Mike

From: William Denniss [mailto:[email-masked]]
Sent: Friday, June 30, 2017 9:33 AM
To: Phil Hunt (IDM) <[email-masked]<mailto:[email-masked]>>
Cc: Nat Sakimura <[email-masked]<mailto:[email-masked]>>; Dick Hardt <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Id-event] Heads-up about SET spec updates

+1 to typ.

Phil

Nat

Phil

Phil

Hi Phil

Thanks!

Phil

                                                                Best wishes,
                                                                -- Mike

---

From: William Denniss <[email-masked]>
Date: Fri, 30 Jun 2017 14:07:41 -0700

Is application/secevent+jwt this following the RFC3023 pattern? i.e.
indicating that it's a secevent primarily, but also a JWT?

On Fri, Jun 30, 2017 at 2:05 PM, Justin Richer <[email-masked]> wrote:

> There had already been discussions, both in Chicago, and in the JWT BCP
> context, that if we were going to use a type identifier, we would use the
> existing “typ” header parameter and not create a new claim.  This is a MIME
> type, with the ability to omit “application/” for space reasons, if desired.
>
> Since there appears to be broad interest in having the ability to use
> explicit typing of the SET, I will plan to define the
> “application/secevent+jwt” MIME type in the SET draft before publishing.
> SETs could then include the “typ”:“secevent+jwt” header parameter value to
> provide explicit typing.  Unless I hear objections soon, I will proceed on
> this basis.
>
>                                                        -- Mike
>
> *From:* William Denniss [mailto:[email-masked] <[email-masked]>]
>
> *Sent:* Friday, June 30, 2017 9:33 AM
> *To:* Phil Hunt (IDM) <[email-masked]>
> *Cc:* Nat Sakimura <[email-masked]>; Dick Hardt <[email-masked]>;
> Mike Jones <[email-masked]>; [email-masked]
> *Subject:* Re: [Id-event] Heads-up about SET spec updates
>
> +1 to typ.
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 30 Jun 2017 21:08:35 +0000

Yes

From: William Denniss [mailto:[email-masked]]
Sent: Friday, June 30, 2017 2:08 PM
To: Justin Richer <[email-masked]>
Cc: Mike Jones <[email-masked]>; Phil Hunt <[email-masked]>; Nat Sakimura <[email-masked]>; [email-masked]; Dick Hardt <[email-masked]>
Subject: Re: [Id-event] Heads-up about SET spec updates

Is application/secevent+jwt this following the RFC3023 pattern? i.e. indicating that it's a secevent primarily, but also a JWT?

On Fri, Jun 30, 2017 at 2:05 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:
Unless there’s an encoding for security events other than JWT, wouldn’t application/secevent suffice?

 — Justin

                                                       -- Mike

+1 to typ.

Phil

Nat

Phil

Phil

Hi Phil

Thanks!

Phil

                                                                Best wishes,
                                                                -- Mike

Nat Sakimura

---

From: Justin Richer <[email-masked]>
Date: Fri, 30 Jun 2017 17:11:49 -0400

Eugh.

 — Justin

> On Jun 30, 2017, at 5:07 PM, Mike Jones <[email-masked]> wrote:
> 
> On Jun 30, 2017, at 12:56 PM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: William Denniss [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Phil Hunt (IDM) <[email-masked] <mailto:[email-masked]>>
> Cc: Nat Sakimura <[email-masked] <mailto:[email-masked]>>; Dick Hardt <[email-masked] <mailto:[email-masked]>>; Mike Jones <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 30 Jun 2017 14:15:27 -0700

AFAIK, sub-profiles of a content format use the + notation as Mike indicates.

application/secevent+jwt makes sense.  

I am about to publish a delivery draft contribution.  I will update it to use application/secevent+jwt instead of application/jwt.

Phil

> On Jun 30, 2017, at 2:05 PM, Justin Richer <[email-masked]> wrote:
> 
>> 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=XQ_uri6FYjC8Tdj2bGebZ6aHjH5IYvsJXr5h0PVrlHA&s=enfdm_8yM-ShqD2mzalK3dP032F8viHYT3x-_hmJWVo&e=>

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Jun 2017 18:17:12 -0400

Having the sender publish the key location or key directly in the message
has even more trust issues.

It is great for attackers if the receiver doesn't verify the key belongs to
the claimed issuer.

John B.

---

From: Leif Johansson <[email-masked]>
Date: Sat, 1 Jul 2017 00:31:40 +0200

On 2017-07-01 00:17, John Bradley wrote:
> Having the sender publish the key location or key directly in the
> message has even more trust issues.  
> 
> It is great for attackers if the receiver doesn't verify the key belongs
> to the claimed issuer.  

key location essentially ties you to the webpki for trust... we've been
here before

---

From: Phil Hunt <[email-masked]>
Date: Fri, 30 Jun 2017 16:25:57 -0700

I’m not sure where this fork in the thread came from.  So, I’m not exactly sure I’m responding to the right thing.

If this is related to my comment, I was concerned that trust bindings should not be part of SET profiles as this might create major incompatibilities for cases with SETs from multiple Event Families need to be distributed as part of a common stream. 

My thinking is that the Trust relationship is part of the Stream more than it is a particular type or set of SETS.

It’s not that somebody can’t do something highly specific. I just don’t think they should unless their intention really is to limit usability.

Phil

> On Jun 30, 2017, at 3:31 PM, Leif Johansson <[email-masked]> wrote:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=JBm5biRrKugCH0FkITSeGJxPEivzjWwlNKe4C_lLIGk&m=0ja-9Vit7qiR1EGhfDAo_YSSBjUcytWPGD_x7n0VYrE&s=B2wBw7YMv11xdZeH4rZPTR0ZBhPia27R_gUgszBulmc&e=

---

From: John Bradley <[email-masked]>
Date: Fri, 30 Jun 2017 22:35:32 -0400

We were replying to the post by Marius in the thred.  Look at my reply.
Leif over snipped.

John B.

On Jun 30, 2017 7:26 PM, "Phil Hunt" <[email-masked]> wrote:

I’m not sure where this fork in the thread came from.  So, I’m not exactly
sure I’m responding to the right thing.

If this is related to my comment, I was concerned that trust bindings
should not be part of SET profiles as this might create major
incompatibilities for cases with SETs from multiple Event Families need to
be distributed as part of a common stream.

My thinking is that the Trust relationship is part of the Stream more than
it is a particular type or set of SETS.

It’s not that somebody can’t do something highly specific. I just don’t
think they should unless their intention really is to limit usability.

Phil

_______________________________________________
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=JBm5biRrKugCH0FkITSeGJxPEivzjW
wlNKe4C_lLIGk&m=0ja-9Vit7qiR1EGhfDAo_YSSBjUcytWPGD_x7n0VYrE&s=
B2wBw7YMv11xdZeH4rZPTR0ZBhPia27R_gUgszBulmc&e=