Subject: [Id-event] Consensus :: Event Subject Claim - resending

From: Yaron Sheffer <[email-masked]>
Date: Sun, 3 Dec 2017 19:39:23 +0200

Do we specify how a subject is included in a SET or let profiles define 
that?

The current draftdraft-ietf-secevent-token-03 
<https://tools.ietf.org/html/draft-ietf-secevent-token-03>defines 
the/sub/claim as an optional string or URI, with semantics left to the 
profile. This claim is placed in the SET envelope. No "subject" claim is 
defined inside the/event/object, which means that profiles are free to 
define such claims as they see fit.

Alternatively, we could have an/event_subject/claim inside 
the/event/object, with a "SHOULD" normative status.

We will track results here: 
https://github.com/IETF-SecEvent/Drafts/issues/2 
<https://github.com/IETF-SecEvent/Drafts/issues/2>

Discussion to be on the mail list as usual, not in the issue tracker!

---

From: Mike Jones <[email-masked]>
Date: Tue, 5 Dec 2017 20:50:41 +0000

I'm fine with the working group deciding to work on an optional event subject claim to be used by some profiles, should people want to do that, provided that doing so does not delay completion of the SET spec.  If pursued, this work should be in a separate specification, with the defined claim being registered in the IANA JWT Claims Registry<https://www.iana.org/assignments/jwt/jwt.xhtml#claims> - especially since some already deployed profiles, such as OpenID Connect Back-Channel Logout<http://openid.net/specs/openid-connect-backchannel-1_0.html#LogoutToken> and I believe others, don't need it.

The idea of a structured event subject claim, while potentially useful in the future, is immature compared to the SET spec, and not yet informed by deployment experience.  Decoupling the SET and Event Subject work will enable us to finish the SET spec soon, while giving time for implementers to provide feedback on their needs for a structured subject claim based on their future deployment experiences.  This result would be the best of both worlds - a completed SET spec soon and a structured subject claim spec once there is data to validate that we've gotten it right for multiple profiles.

But to be clear, I am strongly opposed to trying to jam this new feature still that is still being designed into the already mature SET spec, which would certainly unnecessarily significantly delay its completion.

                                                                -- Mike

-----Original Message-----
From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Sunday, December 3, 2017 9:39 AM
To: SecEvent <[email-masked]>
Subject: [Id-event] Consensus :: Event Subject Claim - resending

Do we specify how a subject is included in a SET or let profiles define that?

The current draftdraft-ietf-secevent-token-03 <https://tools.ietf.org/html/draft-ietf-secevent-token-03>defines

the/sub/claim as an optional string or URI, with semantics left to the profile. This claim is placed in the SET envelope. No "subject" claim is defined inside the/event/object, which means that profiles are free to define such claims as they see fit.

Alternatively, we could have an/event_subject/claim inside the/event/object, with a "SHOULD" normative status.

_______________________________________________

Id-event mailing list

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

https://www.ietf.org/mailman/listinfo/id-event

---

From: Phil Hunt <[email-masked]>
Date: Tue, 5 Dec 2017 13:14:00 -0800

I agree with Mike.

I raised the issue before, but there was little interest. If there is interest now, it would be best addressed as a separate specification.

Further to Mike’s comments, subject claims may be useful for other specification areas that use JWTs — so making it a separate specification has its advantages.

Phil

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

> On Dec 5, 2017, at 12:50 PM, Mike Jones <[email-masked]> wrote:
> 
> I'm fine with the working group deciding to work on an optional event subject claim to be used by some profiles, should people want to do that, provided that doing so does not delay completion of the SET spec.  If pursued, this work should be in a separate specification, with the defined claim being registered in the IANA JWT Claims Registry <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=av4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg&e=>- especially since some already deployed profiles, such as OpenID Connect Back-Channel Logout <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0&e=> and I believe others, don't need it.
>  
> The idea of a structured event subject claim, while potentially useful in the future, is immature compared to the SET spec, and not yet informed by deployment experience.  Decoupling the SET and Event Subject work will enable us to finish the SET spec soon, while giving time for implementers to provide feedback on their needs for a structured subject claim based on their future deployment experiences.  This result would be the best of both worlds – a completed SET spec soon and a structured subject claim spec once there is data to validate that we’ve gotten it right for multiple profiles.
>  
> From: Id-event [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Yaron Sheffer
> To: SecEvent <[email-masked] <mailto:[email-masked]>>
> The current draftdraft-ietf-secevent-token-03 <https://tools.ietf.org/html/draft-ietf-secevent-token-03 <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=>>defines
> https://github.com/IETF-SecEvent/Drafts/issues/2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=>
> <https://github.com/IETF-SecEvent/Drafts/issues/2 <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&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=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=>

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Thu, 7 Dec 2017 08:28:16 +0000

+1

Handling this as a future extension is the right approach. Phil’s last point is also a very good one as this might even help other JWT use cases if kept generic.

Cheers,
Morteza

From: Id-event <[email-masked]> on behalf of Phil Hunt <[email-masked]>
Date: Tuesday, December 5, 2017 at 1:14 PM
To: Mike Jones <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]>
Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending

I agree with Mike.

Phil

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

On Dec 5, 2017, at 12:50 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

I'm fine with the working group deciding to work on an optional event subject claim to be used by some profiles, should people want to do that, provided that doing so does not delay completion of the SET spec.  If pursued, this work should be in a separate specification, with the defined claim being registered in the IANA JWT Claims Registry<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=av4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg&e=>- especially since some already deployed profiles, such as OpenID Connect Back-Channel Logout<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0&e=> and I believe others, don't need it.

                                                                -- Mike

-----Original Message-----
From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Sunday, December 3, 2017 9:39 AM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: [Id-event] Consensus :: Event Subject Claim - resending

The current draftdraft-ietf-secevent-token-03 <https://tools.ietf.org/html/draft-ietf-secevent-token-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=>>defines
the/sub/claim as an optional string or URI, with semantics left to the profile. This claim is placed in the SET envelope. No "subject" claim is defined inside the/event/object, which means that profiles are free to define such claims as they see fit.

We will track results here:
https://github.com/IETF-SecEvent/Drafts/issues/2<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=>
<https://github.com/IETF-SecEvent/Drafts/issues/2<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&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=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 7 Dec 2017 11:48:55 -0800

Here is my comment on the original thread (not sure why was that thread
split):

Defining an "event_subject" claim would help interop and add real value to
the SET spec.

We also need a way to specif multiple alternative subjects. We talked about
using a separate claim for that. Here is an example:

{
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "iss": "https://transmitter.example.com",
     "aud": [ "https://receiver.example.com" ],
     "iat": 1458496025,
     "event": {
       "event_type": "https://secevent.example.com/example_event",
       "event_subject": {
         "identifier_type": "urn:ietf:params:secevent:subject:email",
         "email": "[email-masked]"
       },
       "event_subject_alt": [
         {
           "identifier_type": "urn:ietf:params:secevent:subject:connect",
           "iss": "https://idp.example.com",
           "sub": "abc123",
         },
         {
           "identifier_type": "urn:ietf:params:secevent:subject:phone",
           "phone_number": "+40-123-456-789",
         },
       ],
       "event_time": 1458492425,
       "claim_1": "foo",
       "claim_2": "bar"
     }
   }

Important note: the event_subject and event_subject_alt claims are
orthogonal to the events vs event discussion, it can be applied to either.

I think this should be added to the current SET spec and not a separate
spec. Yes, it will slow down the SET spec, but that is unavoidable and very
necessary. Implementations will have to wait for the subject claim spec
anyhow. The real questions speed question is this: will two specs be faster
than adding to the existing one? And speed is not the only criteria.
Defining some generic JWT spec to specify subjects will take a long time I
am afraid, it is a much larger problem, let's not boil the ocean.

This new subject claim should probably be optional and back-channel logout
should probably not be forced to use it. I am saying probably, since we
don't want to put the cart before the horse.

Marius

On Thu, Dec 7, 2017 at 12:28 AM, Morteza Ansari (moransar) <
[email-masked]> wrote:

> +1
>
>
>
> Handling this as a future extension is the right approach. Phil’s last
> point is also a very good one as this might even help other JWT use cases
> if kept generic.
>
>
>
>
>
> Cheers,
>
> Morteza
>
>
>
> *From: *Id-event <[email-masked]> on behalf of Phil Hunt <
> [email-masked]>
> *Date: *Tuesday, December 5, 2017 at 1:14 PM
> *To: *Mike Jones <[email-masked]>
> *Cc: *Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]>
> *Subject: *Re: [Id-event] Consensus :: Event Subject Claim - resending
>
>
>
> I agree with Mike.
>
>
>
> I raised the issue before, but there was little interest. If there is
> interest now, it would be best addressed as a separate specification.
>
>
>
> Further to Mike’s comments, subject claims may be useful for other
> specification areas that use JWTs — so making it a separate specification
> has its advantages.
>
>
>
> Phil
>
>
>
> www.independentid.com
> [email-masked]
> I'm fine with the working group deciding to work on an optional event
> subject claim to be used by some profiles, should people want to do that,
> provided that doing so does not delay completion of the SET spec.  If
> pursued, this work should be in a separate specification, with the defined
> claim being registered in the IANA JWT Claims Registry
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=av4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg&e=>-
> especially since some already deployed profiles, such as OpenID Connect
> Back-Channel Logout
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0&e=>
>  and I believe others, don't need it.
>
>
>
> The idea of a structured event subject claim, while potentially useful in
> the future, is immature compared to the SET spec, and not yet informed by
> deployment experience.  Decoupling the SET and Event Subject work will
> enable us to finish the SET spec soon, while giving time for implementers
> to provide feedback on their needs for a structured subject claim based on
> their future deployment experiences.  This result would be the best of both
> worlds – a completed SET spec soon and a structured subject claim spec once
> there is data to validate that we’ve gotten it right for multiple profiles.
>
>
>
> But to be clear, I am strongly opposed to trying to jam this new feature
> still that is still being designed into the already mature SET spec, which
> would certainly unnecessarily significantly delay its completion.
>
>
>
>                                                                 -- Mike
>
>
>
> From: Id-event [mailto:[email-masked]
> <[email-masked]>] On Behalf Of Yaron Sheffer
> The current draftdraft-ietf-secevent-token-03 <
> https://tools.ietf.org/html/draft-ietf-secevent-token-03
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=>
> >defines
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=>
>
> <https://github.com/IETF-SecEvent/Drafts/issues/2
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=>
> >
>
>
>
> [email-masked]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=>
>
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=
> UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=
>
>
>
> [email-masked]

---

From: Mike Jones <[email-masked]>
Date: Thu, 7 Dec 2017 19:54:55 +0000

Marius – you say that “it will slow down the SET spec, but that is unavoidable and very necessary. Implementations will have to wait for the subject claim spec anyhow.”

Both of these statements are incorrect.  Slowing down the SET spec is *totally avoidable* because any new event subject claim can be added via the JWT Claims Registry in a separate spec.  That’s what registries are intended to enable!

Also, implementations not using this new claim, such as OpenID Connect Back-Channel Logout, *will not have to wait*, because the existing working group spec already totally does the job.  It’s time for us to finish it!

We should not block the SET spec, which is mature, on new work that can and should be decoupled, and is still in its formative stages.

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Thursday, December 7, 2017 11:49 AM
To: Morteza Ansari (moransar) <[email-masked]>
Cc: Phil Hunt <[email-masked]>; Mike Jones <[email-masked]>; Yaron Sheffer <[email-masked]>; SecEvent <[email-masked]>
Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending

Here is my comment on the original thread (not sure why was that thread split):

Defining an "event_subject" claim would help interop and add real value to the SET spec.

We also need a way to specif multiple alternative subjects. We talked about using a separate claim for that. Here is an example:

{
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "iss": "https://transmitter.example.com<https://transmitter.example.com/>",
     "aud": [ "https://receiver.example.com<https://receiver.example.com/>" ],
     "iat": 1458496025,
     "event": {
       "event_type": "https://secevent.example.com/example_event",
       "event_subject": {
         "identifier_type": "urn:ietf:params:secevent:subject:email",
         "email": "[email-masked]<mailto:[email-masked]>"
       },
       "event_subject_alt": [
         {
           "identifier_type": "urn:ietf:params:secevent:subject:connect",
           "iss": "https://idp.example.com<https://idp.example.com/>",
           "sub": "abc123",
         },
         {
           "identifier_type": "urn:ietf:params:secevent:subject:phone",
           "phone_number": "+40-123-456-789",
         },
       ],
       "event_time": 1458492425,
       "claim_1": "foo",
       "claim_2": "bar"
     }
   }

Important note: the event_subject and event_subject_alt claims are orthogonal to the events vs event discussion, it can be applied to either.

I think this should be added to the current SET spec and not a separate spec. Yes, it will slow down the SET spec, but that is unavoidable and very necessary. Implementations will have to wait for the subject claim spec anyhow. The real questions speed question is this: will two specs be faster than adding to the existing one? And speed is not the only criteria. Defining some generic JWT spec to specify subjects will take a long time I am afraid, it is a much larger problem, let's not boil the ocean.

This new subject claim should probably be optional and back-channel logout should probably not be forced to use it. I am saying probably, since we don't want to put the cart before the horse.

Marius

On Thu, Dec 7, 2017 at 12:28 AM, Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>> wrote:
+1

Cheers,
Morteza

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of Phil Hunt <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, December 5, 2017 at 1:14 PM
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] Consensus :: Event Subject Claim - resending

I agree with Mike.

Phil

                                                                -- Mike

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 7 Dec 2017 23:21:53 +0200

Simplicity was one of the things that made JWT successful. Let's find a
way to preserve that simplicity in the SET.

When we implemented SETs internally (based on
draft-ietf-secevent-token-00) I urged developers to keep the events
simple, and this has worked quite well so far. The "events" is often
just an identifier. We didn't find use for the "toe" and "txn" claims.

Let's keep the SET format simple and still JWT-like, for those people
who need to convey relatively simple events, and don't need the extra
complexity. I believe this will greatly help adoption and make the SET
work here more successful. If there are people who need to shuffle
complex events around, e.g. with multiple subjects, the current "events"
structure already permits that. Applications can define profiles for
that, if needed. But let's keep the basics simple.

I therefore support the suggestion to leave an event-specific subject
claim out of the core SET spec. The current SET has already got enough
claims.

I doubt we can come up with an adequate event subject claim format /
structure that will work for the majority of current and future
applications out there. This job better be left to the application
designers who know their domain, their events, and what's expected of them.

Thanks,

Vladimir

On 07/12/17 21:48, Marius Scurtescu wrote:
>> ___________________________________________

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 7 Dec 2017 16:56:15 -0800

On Thu, Dec 7, 2017 at 11:54 AM, Mike Jones <[email-masked]>
wrote:

> Marius – you say that “it will slow down the SET spec, but that is
> unavoidable and very necessary. Implementations will have to wait for the
> subject claim spec anyhow.”
>
>
>
> Both of these statements are incorrect.  Slowing down the SET spec is **totally
> avoidable** because any new event subject claim can be added via the JWT
> Claims Registry in a separate spec.  That’s what registries are intended to
> enable!
>

Most implementors will have to wait for the event subject claim as well,
and they will be slowed down even more.

>
>
> Also, implementations not using this new claim, such as OpenID Connect
> Back-Channel Logout, **will not have to wait**, because the existing
> working group spec already totally does the job.  It’s time for us to
> finish it!
>

How is back-channel affected in either case? It will not use a new event
subject claim, so it does matter. Everyone else will be affected as stated
above.

>
>
> We should not block the SET spec, which is mature, on new work that can
> and should be decoupled, and is still in its formative stages.
>

Again, if it was mature we would not have all these threads. Using maturity
as a reason to refuse feedback makes no sense.

>
>
>                                                        -- Mike
>
>
>
> *From:* Marius Scurtescu [mailto:[email-masked]]
> *Sent:* Thursday, December 7, 2017 11:49 AM
> *To:* Morteza Ansari (moransar) <[email-masked]>
> *Cc:* Phil Hunt <[email-masked]>; Mike Jones <
> [email-masked]>; Yaron Sheffer <[email-masked]>;
> SecEvent <[email-masked]>
>
> *Subject:* Re: [Id-event] Consensus :: Event Subject Claim - resending
>
>
>
> We also need a way to specif multiple alternative subjects. We talked
> about using a separate claim for that. Here is an example:
>
>
>
> {
>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 7 Dec 2017 17:00:12 -0800

> designers who know their domain, their events, and what's expected of them.

In this thread it is suggested to create just a claim, not the format,
please read again. There is a separate thread that proposes to also define
a few common formats.

Defining a claim provides a clear extension point for profiles, otherwise
each profile will have to invent a different claim with potential confusion
and conflicts.

> about
> >> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims&d=DwMFAg&c=
> av4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg&e=>-
> >> <https://urldefense.proofpoint.com/v2/url?u=http-
> 3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-
> 5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIr
> MUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_
> svnmaKgt3oIQDMddR09ByNql0&e=>
> >> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=
> cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=>
> >>> defines
> >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-
> 2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIr
> MUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_
> BVWLcUJObCaxUrhs&e=>
> >>
> >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-
> 2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIr
> MUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=
> aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_
> BVWLcUJObCaxUrhs&e=>
> >>
> >>
> >> <https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFAg&c=
> UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=>
> >>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 7 Dec 2017 17:15:09 -0800

Scim and backchannel do not need it. They would like to move on. 

Phil

> On Dec 7, 2017, at 4:56 PM, Marius Scurtescu <[email-masked]> wrote:
> 
>> On Thu, Dec 7, 2017 at 11:54 AM, Mike Jones <[email-masked]> wrote:
> Most implementors will have to wait for the event subject claim as well, and they will be slowed down even more.
>  
>>  
>> 
> How is back-channel affected in either case? It will not use a new event subject claim, so it does matter. Everyone else will be affected as stated above.
>  
>>  
>> 
> Again, if it was mature we would not have all these threads. Using maturity as a reason to refuse feedback makes no sense.
> 
>  
>>  
>> 
>>                                                        -- Mike
>> 
>>  
>> 
>> On Thu, Dec 7, 2017 at 12:28 AM, Morteza Ansari (moransar) <[email-masked]> wrote:
>> 
>> +1
>> 
>>  
>> 
>> I'm fine with the working group deciding to work on an optional event subject claim to be used by some profiles, should people want to do that, provided that doing so does not delay completion of the SET spec.  If pursued, this work should be in a separate specification, with the defined claim being registered in the IANA JWT Claims Registry- especially since some already deployed profiles, such as OpenID Connect Back-Channel Logout and I believe others, don't need it.
>> 
>>  
>>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 7 Dec 2017 20:02:45 -0800

> Scim and backchannel do not need it. They would like to move on.

Right. You and Mike are editors of the spec, are you making a spec just for
the two of you?

How is SCIM pointing to the subject? Always using iss+sub? SCIM will never
be in the situation where the subject issuer is different from the SET
issuer?

Again, this thread is not asking for a major change, it is asking to add a
claim name that can be used by profiles as an extension point. There is the
question of alternative subject identifiers, so some discussion is
necessary.

> Again, if it was mature we would not have all these threads. Using
> maturity as a reason to refuse feedback makes no sense.
>
>
>
>>
>>
>>                                                        -- Mike
>>
>>
>>
>> This new subject claim should probably be optional and back-channel
>> logout should probably not be forced to use it. I am saying probably, since
>> we don't want to put the cart before the horse.
>>
>>
>>
>>
>>
>>
>> Marius
>>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM&s=337h9ahCqEnkyo3wKcMrEVWEEXSZ5HswVurVvXBet9k&e=>
>>
>> [email-masked]
>>
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>> f.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHv
>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYq
>> PkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_
>> ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=
>>
>>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM&s=o3JZgDc6WNNqDqIl_RSgzBmT4KEget2lduea5cfV5fA&e=>
>>
>>
>>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 8 Dec 2017 11:34:03 -0800

That is a bit unfair. RISC is as important to me as the rest. 

You have commented you want pilots by end of year. That is what we are working towards. 

Phil

> On Dec 7, 2017, at 8:02 PM, Marius Scurtescu <[email-masked]> wrote:
> 
> Right. You and Mike are editors of the spec, are you making a spec just for the two of you?
> 
> How is SCIM pointing to the subject? Always using iss+sub? SCIM will never be in the situation where the subject issuer is different from the SET issuer?
> 
> Again, this thread is not asking for a major change, it is asking to add a claim name that can be used by profiles as an extension point. There is the question of alternative subject identifiers, so some discussion is necessary.
>  
>> 
>> 
>> Phil
>> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qCsVU8GSrNishJH840WEp7RRVV5Qyt_dAFLnIxZdXrA&s=hWumbgAlx3vB4z_y8DRi4w6VEh7XVep0LAn9KBC5Ds0&e=

---

From: William Denniss <[email-masked]>
Date: Fri, 8 Dec 2017 14:37:26 -0600

I don't think we need to specify how profiles will use 'sub' in the event
payload. +1 to Morteza's comment that profiles can specify the subject in
the event payload as they see fit. The existing text reads well to me.

   sub  As defined by Section 4.1.2 [RFC7519], a String or URI value
      representing the principal or the subject of the SET.  This is
      usually the entity whose "state" was changed.  For example, an IP
      Address was added to a black list.  A URI representing a user
      resource that was modified.  A token identifier for a revoked
      token.  If used, the Profiling Specification SHOULD define the
      content and format semantics for the value.  This claim is
      OPTIONAL, as the principal for any given profile may already be
      identified without the inclusion of a subject claim.  Note that
      some SET profiles MAY choose to convey event subject information
      in the event payload (either using the "sub" member name or
      another name), particularly if the subject information is relative
      to issuer information that is also conveyed in the event payload,
      which may be the case for some identity SET profiles.

On Fri, Dec 8, 2017 at 1:34 PM, Phil Hunt <[email-masked]> wrote:

>>> avoidable** because any new event subject claim can be added via the
>>> JWT Claims Registry in a separate spec.  That’s what registries are
>>> intended to enable!
>>>
>>
>>> *Cc: *Yaron Sheffer <[email-masked]>, SecEvent <[email-masked]
>>> >
>>> The idea of a structured event subject claim, while potentially useful
>>> in the future, is immature compared to the SET spec, and not yet informed
>>> by deployment experience.  Decoupling the SET and Event Subject work will
>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
>>> kAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps
>>> &s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=
>>>
>>>
>>>
>>>
> qCsVU8GSrNishJH840WEp7RRVV5Qyt_dAFLnIxZdXrA&s=hWumbgAlx3vB4z_
> y8DRi4w6VEh7XVep0LAn9KBC5Ds0&e=
>
>

---

From: Justin Richer <[email-masked]>
Date: Sun, 10 Dec 2017 11:09:17 -0500

Vladimir,

I have to completely disagree with this stance. With this attitude, I 
ask: what's left to put in the SET document? It sounds like some people 
want a draft that is effectively:

1. Take a JWT

2. Add an "events" object to it. The keys are URLs and the values are 
whatever.

3. Done

Is that really what we're doing here? Because in my view, the group came 
together from the consent receipts, risc, oidc, and eventually other 
groups like the scim folks, in order to find *commonality*. If the SET 
is going to be "just a JWT" then I say we close up shop because we don't 
need a standard for this. What commonality and interoperability does 
this position buy us?

I agree that simplicity is a major key to success, which is why I argue 
for the new, simpler syntax and data model. It's deterministic and clear 
to process.

Do I wish we'd thought of this the first time through? Sure. But coming 
up with a bad idea first doesn't make it a good idea.

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Sun, 10 Dec 2017 11:26:51 -0500

The question isn't about using "sub", it's about creating a new, more 
expressive mechanism for expressing subjects with clear semantics on 
reading the subject data. The "sub" for a JWT is much more clear than 
the "sub" for a SET.

  -- Justin

On 12/8/2017 3:37 PM, William Denniss wrote:
> I don't think we need to specify how profiles will use 'sub' in the 
> event payload. +1 to Morteza's comment that profiles can specify the 
> subject in the event payload as they see fit. The existing text reads 
> well to me.
>
> On Fri, Dec 8, 2017 at 1:34 PM, Phil Hunt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Dec 7, 2017, at 8:02 PM, Marius Scurtescu
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     On Thu, Dec 7, 2017 at 5:15 PM, Phil Hunt <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     How is SCIM pointing to the subject? Always using iss+sub? SCIM
>>     will never be in the situation where the subject issuer is
>>     different from the SET issuer?
>>
>>     Again, this thread is not asking for a major change, it is asking
>>     to add a claim name that can be used by profiles as an extension
>>     point. There is the question of alternative subject identifiers,
>>     so some discussion is necessary.
>>
>>
>>
>>         Phil
>>
>>         On Dec 7, 2017, at 4:56 PM, Marius Scurtescu
>>         <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>         On Thu, Dec 7, 2017 at 11:54 AM, Mike Jones
>>>         <[email-masked]
>>>         <mailto:[email-masked]>> wrote:
>>>
>>>             Marius – you say that “it will slow down the SET spec,
>>>             but that is unavoidable and very necessary.
>>>             Implementations will have to wait for the subject claim
>>>             spec anyhow.”
>>>
>>>             Both of these statements are incorrect.  Slowing down
>>>             the SET spec is **totally avoidable** because any new
>>>             event subject claim can be added via the JWT Claims
>>>             Registry in a separate spec. That’s what registries are
>>>             intended to enable!
>>>
>>>
>>>         Most implementors will have to wait for the event subject
>>>         claim as well, and they will be slowed down even more.
>>>
>>>             Also, implementations not using this new claim, such as
>>>             OpenID Connect Back-Channel Logout, **will not have to
>>>             wait**, because the existing working group spec already
>>>             totally does the job. It’s time for us to finish it!
>>>
>>>
>>>         How is back-channel affected in either case? It will not use
>>>         a new event subject claim, so it does matter. Everyone else
>>>         will be affected as stated above.
>>>
>>>             We should not block the SET spec, which is mature, on
>>>             new work that can and should be decoupled, and is still
>>>             in its formative stages.
>>>
>>>
>>>         Again, if it was mature we would not have all these threads.
>>>         Using maturity as a reason to refuse feedback makes no sense.
>>>
>>>             -- Mike
>>>
>>>             *From:* Marius Scurtescu [mailto:[email-masked]
>>>             <mailto:[email-masked]>]
>>>             *To:* Morteza Ansari (moransar) <[email-masked]
>>>             <mailto:[email-masked]>>
>>>             *Cc:* Phil Hunt <[email-masked]
>>>             <mailto:[email-masked]>>; Mike Jones
>>>             <[email-masked]
>>>             <mailto:[email-masked]>>; Yaron Sheffer
>>>             <[email-masked] <mailto:[email-masked]>>;
>>>             SecEvent <[email-masked] <mailto:[email-masked]>>
>>>
>>>
>>>             We also need a way to specif multiple alternative
>>>             subjects. We talked about using a separate claim for
>>>             that. Here is an example:
>>>
>>>             {
>>>
>>>              "event_type":
>>>             "https://secevent.example.com/example_event
>>>             <https://secevent.example.com/example_event>",
>>>
>>>              "event_subject": {
>>>
>>>              "identifier_type":
>>>             "urn:ietf:params:secevent:subject:email",
>>>
>>>              "email": "[email-masked] <mailto:[email-masked]>"
>>>
>>>                    },
>>>
>>>              "event_subject_alt": [
>>>
>>>                      {
>>>
>>>              "identifier_type":
>>>             "urn:ietf:params:secevent:subject:connect",
>>>
>>>              "identifier_type":
>>>             "urn:ietf:params:secevent:subject:phone",
>>>
>>>             Important note: the event_subject and event_subject_alt
>>>             claims are orthogonal to the events vs event discussion,
>>>             it can be applied to either.
>>>
>>>             I think this should be added to the current SET spec and
>>>             not a separate spec. Yes, it will slow down the SET
>>>             spec, but that is unavoidable and very necessary.
>>>             Implementations will have to wait for the subject claim
>>>             spec anyhow. The real questions speed question is this:
>>>             will two specs be faster than adding to the existing
>>>             one? And speed is not the only criteria. Defining some
>>>             generic JWT spec to specify subjects will take a long
>>>             time I am afraid, it is a much larger problem, let's not
>>>             boil the ocean.
>>>
>>>             This new subject claim should probably be optional and
>>>             back-channel logout should probably not be forced to use
>>>             it. I am saying probably, since we don't want to put the
>>>             cart before the horse.
>>>
>>>
>>>             Marius
>>>
>>>             On Thu, Dec 7, 2017 at 12:28 AM, Morteza Ansari
>>>             (moransar) <[email-masked]
>>>             <mailto:[email-masked]>> wrote:
>>>
>>>                 +1
>>>
>>>                 Handling this as a future extension is the right
>>>                 approach. Phil’s last point is also a very good one
>>>                 as this might even help other JWT use cases if kept
>>>                 generic.
>>>
>>>                 Cheers,
>>>
>>>                 Morteza
>>>
>>>                 *From: *Id-event <[email-masked]
>>>                 <mailto:[email-masked]>> on behalf of
>>>                 Phil Hunt <[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]>>
>>>                 I raised the issue before, but there was little
>>>                 interest. If there is interest now, it would be best
>>>                 addressed as a separate specification.
>>>
>>>                 Further to Mike’s comments, subject claims may be
>>>                 useful for other specification areas that use JWTs —
>>>                 so making it a separate specification has its
>>>                 advantages.
>>>
>>>                 Phil
>>>
>>>                 [email-masked] <mailto:[email-masked]>
>>>
>>>                     On Dec 5, 2017, at 12:50 PM, Mike Jones
>>>                     <[email-masked]
>>>                     <mailto:[email-masked]>> wrote:
>>>
>>>                     I'm fine with the working group deciding to work
>>>                     on an optional event subject claim to be used by
>>>                     some profiles, should people want to do that,
>>>                     provided that doing so does not delay completion
>>>                     of the SET spec. If pursued, this work should be
>>>                     in a separate specification, with the defined
>>>                     claim being registered in theIANA JWT Claims
>>>                     Registry
>>>                     especially since some already deployed profiles,
>>>                     such asOpenID Connect Back-Channel Logout
>>>                     <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0&e=>and
>>>                     I believe others, don't need it.
>>>
>>>                     The idea of a structured event subject claim,
>>>                     while potentially useful in the future, is
>>>                     immature compared to the SET spec, and not yet
>>>                     informed by deployment experience. Decoupling
>>>                     the SET and Event Subject work will enable us to
>>>                     finish the SET spec soon, while giving time for
>>>                     implementers to provide feedback on their needs
>>>                     for a structured subject claim based on their
>>>                     future deployment experiences. This result would
>>>                     be the best of both worlds – a completed SET
>>>                     spec soon and a structured subject claim spec
>>>                     once there is data to validate that we’ve gotten
>>>                     it right for multiple profiles.
>>>
>>>                     But to be clear, I am strongly opposed to trying
>>>                     to jam this new feature still that is still
>>>                     being designed into the already mature SET spec,
>>>                     which would certainly unnecessarily
>>>                     significantly delay its completion.
>>>
>>>                     -- Mike
>>>
>>>                     <mailto:[email-masked]>] On Behalf Of
>>>                     Yaron Sheffer
>>>                     <https://tools.ietf.org/html/draft-ietf-secevent-token-03
>>>                     <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=>>defines
>>>
>>>                     the/sub/claim as an optional string or URI, with
>>>                     semantics left to the profile. This claim is
>>>                     placed in the SET envelope. No "subject" claim
>>>                     is defined inside the/event/object, which means
>>>                     that profiles are free to define such claims as
>>>                     they see fit.
>>>
>>>                     Alternatively, we could have
>>>                     an/event_subject/claim inside the/event/object,
>>>                     with a "SHOULD" normative status.
>>>
>>>                     <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=>>
>>>
>>>                     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=>
>>>
>>>
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qCsVU8GSrNishJH840WEp7RRVV5Qyt_dAFLnIxZdXrA&s=hWumbgAlx3vB4z_y8DRi4w6VEh7XVep0LAn9KBC5Ds0&e=>
>
>     <https://www.ietf.org/mailman/listinfo/id-event>
>
>
>
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 11 Dec 2017 22:25:13 +0200

Hi Justin,

If the original intent of the group was to find commonality, and later
is found that the common denominator is smaller than intended, that's
not a failure, and it certainly doesn't disqualify the work done here,
or make it less important.

There's great value in specs that solve complex technical issues. Specs
that codify a standard format or language for things are at least
equally valuable. Even if they're simple. Think of traffic lights for
instance - nothing really complicated, but hugely useful.

What you articulated so nicely -- take a JWT and add an "events" object
to it -- that cannot be horribly wrong. It's actually quite brilliant,
flexible if needed, and simple to explain too.

Vladimir

On 10/12/17 18:09, Justin Richer wrote:
> ask: what's left to put in the SET document? It sounds like some
> people want a draft that is effectively:
>
> 1. Take a JWT
>
> Is that really what we're doing here? Because in my view, the group
> came together from the consent receipts, risc, oidc, and eventually
> other groups like the scim folks, in order to find *commonality*. If
> the SET is going to be "just a JWT" then I say we close up shop
> because we don't need a standard for this. What commonality and
> interoperability does this position buy us?
>
> I agree that simplicity is a major key to success, which is why I
> argue for the new, simpler syntax and data model. It's deterministic
> and clear to process.
>
> Do I wish we'd thought of this the first time through? Sure. But
> coming up with a bad idea first doesn't make it a good idea.
>
>  -- Justin
>
>
>>> logout
>>>>                                                                  --
>>>> Mike

---

From: Justin Richer <[email-masked]>
Date: Mon, 11 Dec 2017 15:45:56 -0500

My problem here is that the commonality is being needlessly limited by a a few members of the group. 

We don’t need commonality on something so simple — what on earth would a general purpose SET library do with a spec so small? If that’s all we end up with, we haven’t made a standard, we’ve allowed a bunch of unrelated standards claim they’re compliant with something.

 — Justin

> On Dec 11, 2017, at 3:25 PM, Vladimir Dzhuvinov <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Hi Justin,
> 
> If the original intent of the group was to find commonality, and later is found that the common denominator is smaller than intended, that's not a failure, and it certainly doesn't disqualify the work done here, or make it less important.
> 
> There's great value in specs that solve complex technical issues. Specs that codify a standard format or language for things are at least equally valuable. Even if they're simple. Think of traffic lights for instance - nothing really complicated, but hugely useful.
> 
> What you articulated so nicely -- take a JWT and add an "events" object to it -- that cannot be horribly wrong. It's actually quite brilliant, flexible if needed, and simple to explain too.
> Vladimir
> 
>> I have to completely disagree with this stance. With this attitude, I ask: what's left to put in the SET document? It sounds like some people want a draft that is effectively: 
>> 
>> 1. Take a JWT 
>> 
>> 2. Add an "events" object to it. The keys are URLs and the values are whatever. 
>> 
>> 3. Done 
>> 
>> Is that really what we're doing here? Because in my view, the group came together from the consent receipts, risc, oidc, and eventually other groups like the scim folks, in order to find *commonality*. If the SET is going to be "just a JWT" then I say we close up shop because we don't need a standard for this. What commonality and interoperability does this position buy us? 
>> 
>> I agree that simplicity is a major key to success, which is why I argue for the new, simpler syntax and data model. It's deterministic and clear to process. 
>> 
>> Do I wish we'd thought of this the first time through? Sure. But coming up with a bad idea first doesn't make it a good idea. 
>> 
>>  -- Justin 
>> 
>> 
>>>>       "iss": "https://transmitter.example.com" <https://transmitter.example.com/>, 
>>>>       "aud": [ "https://receiver.example.com" <https://receiver.example.com/> ], 
>>>>       "iat": 1458496025, 
>>>>       "event": { 
>>>>         "event_type": "https://secevent.example.com/example_event" <https://secevent.example.com/example_event>, 
>>>>         "event_subject": { 
>>>>           "email": "[email-masked]" <mailto:[email-masked]> 
>>>>         }, 
>>>>         "event_subject_alt": [ 
>>>>           { 
>>>>             "iss": "https://idp.example.com" <https://idp.example.com/>, 
>>>>             "sub": "abc123", 
>>>>           }, 
>>>>           { 
>>>> [email-masked] <mailto:[email-masked]>> wrote: 
>>>> 
>>>>> +1 
>>>>> 
>>>>> 
>>>>> 
>>>>> *From: *Id-event <[email-masked]> <mailto:[email-masked]> on behalf of Phil Hunt < 
>>>>> [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]> 
>>>>> www.independentid.com <http://www.independentid.com/> 
>>>>> 
>>>>> On Dec 5, 2017, at 12:50 PM, Mike Jones <[email-masked]> <mailto:[email-masked]> 
>>>>> wrote: 
>>>>> 
>>>>> 
>>>>> 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=av4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg&e=> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=av4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg&e=>- 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0&e=> <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0&e=> 
>>>>> From: Id-event [mailto:[email-masked] <mailto:[email-masked]> 
>>>>> <[email-masked]> <mailto:[email-masked]>] On Behalf Of Yaron Sheffer 
>>>>> To: SecEvent <[email-masked]> <mailto:[email-masked]> 
>>>>> https://tools.ietf.org/html/draft-ietf-secevent-token-03 <https://tools.ietf.org/html/draft-ietf-secevent-token-03> 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=> 
>>>>>> defines 
>>>>> https://github.com/IETF-SecEvent/Drafts/issues/2 <https://github.com/IETF-SecEvent/Drafts/issues/2> 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=> 
>>>>> 
>>>>> <https://github.com/IETF-SecEvent/Drafts/issues/2 <https://github.com/IETF-SecEvent/Drafts/issues/2> 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=> 
>>>>> 
>>>>> 
>>>>> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event> 
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=> 
>>>>> 
>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www <https://urldefense.proofpoint.com/v2/url?u=https-3A__www>. 
>>> 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: Mike Jones <[email-masked]>
Date: Mon, 11 Dec 2017 22:07:50 +0000

+1

It’s this very simplicity, JWT + the “events” claim, that makes the SET spec compelling and general purpose.  We already have it just right.

                                                       -- Mike

From: Id-event [mailto:[email-masked]] On Behalf Of Vladimir Dzhuvinov
Sent: Monday, December 11, 2017 3:25 PM
To: [email-masked]
Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending

Hi Justin,

Vladimir

1. Take a JWT

3. Done

 -- Justin

Thanks,

Vladimir

{
      "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
      "iss": "https://transmitter.example.com"<https://transmitter.example.com>,
      "aud": [ "https://receiver.example.com"<https://receiver.example.com> ],
      "iat": 1458496025,
      "event": {
        "event_type": "https://secevent.example.com/example_event"<https://secevent.example.com/example_event>,
        "event_subject": {
          "identifier_type": "urn:ietf:params:secevent:subject:email",
          "email": "[email-masked]"<mailto:[email-masked]>
        },
        "event_subject_alt": [
          {
            "identifier_type": "urn:ietf:params:secevent:subject:connect",
            "iss": "https://idp.example.com"<https://idp.example.com>,
            "sub": "abc123",
          },
          {
            "identifier_type": "urn:ietf:params:secevent:subject:phone",
            "phone_number": "+40-123-456-789",
          },
        ],
        "event_time": 1458492425,
        "claim_1": "foo",
        "claim_2": "bar"
      }
    }

Marius

On Thu, Dec 7, 2017 at 12:28 AM, Morteza Ansari (moransar) <
[email-masked]<mailto:[email-masked]>> wrote:

+1

Cheers,

Morteza

*From: *Id-event <[email-masked]><mailto:[email-masked]> on behalf of Phil Hunt <
[email-masked]<mailto:[email-masked]>>
*Date: *Tuesday, December 5, 2017 at 1:14 PM
*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] Consensus :: Event Subject Claim - resending

I agree with Mike.

Phil

@independentid

On Dec 5, 2017, at 12:50 PM, Mike Jones <[email-masked]><mailto:[email-masked]>
wrote:

I'm fine with the working group deciding to work on an optional event
subject claim to be used by some profiles, should people want to do that,
provided that doing so does not delay completion of the SET spec.  If
pursued, this work should be in a separate specification, with the defined
claim being registered in the IANA JWT Claims Registry
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=av4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=av4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg&e=>-
especially since some already deployed profiles, such as OpenID Connect
Back-Channel Logout
<https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0&e=><https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0&e=>
  and I believe others, don't need it.

                                                                 -- Mike

-----Original Message-----
From: Id-event [mailto:[email-masked]
<[email-masked]><mailto:[email-masked]>] On Behalf Of Yaron Sheffer
Sent: Sunday, December 3, 2017 9:39 AM
To: SecEvent <[email-masked]><mailto:[email-masked]>
Subject: [Id-event] Consensus :: Event Subject Claim - resending

The current draftdraft-ietf-secevent-token-03 <
https://tools.ietf.org/html/draft-ietf-secevent-token-03
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=cOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI&e=>

defines

https://github.com/IETF-SecEvent/Drafts/issues/2
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=>

<https://github.com/IETF-SecEvent/Drafts/issues/2
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_IETF-2DSecEvent_Drafts_issues_2&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=KR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs&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=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=>

Id-event mailing list

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Dec 2017 19:50:10 -0300

I have a feeling that defining a extendable structured subject may be a never ending task.

It is probably best to leave it to the profiles if they need something other than sub.

We have a registry that can be used.

I think I am missing the value of reserving a name in this spec as a extension point.

Are some of you thinking that we would define set_subject (or some such) as a dict and let some other spec define what goes in the dict?  

John

> On Dec 8, 2017, at 5:37 PM, William Denniss <[email-masked]> wrote:
> 
> I don't think we need to specify how profiles will use 'sub' in the event payload. +1 to Morteza's comment that profiles can specify the subject in the event payload as they see fit. The existing text reads well to me.
> 
> On Fri, Dec 8, 2017 at 1:34 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
> On Dec 7, 2017, at 8:02 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Thu, Dec 7, 2017 at 5:15 PM, Phil Hunt <[email-masked] <mailto:[email-masked]>> wrote:
>> On Dec 7, 2017, at 4:56 PM, Marius Scurtescu <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On Thu, Dec 7, 2017 at 11:54 AM, Mike Jones <[email-masked] <mailto:[email-masked]>> wrote:
>>>   <>
>>> From: Marius Scurtescu [mailto:[email-masked] <mailto:[email-masked]>] 
>>> To: Morteza Ansari (moransar) <[email-masked] <mailto:[email-masked]>>
>>> Cc: Phil Hunt <[email-masked] <mailto:[email-masked]>>; Mike Jones <[email-masked] <mailto:[email-masked]>>; Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; SecEvent <[email-masked] <mailto:[email-masked]>>
>>> 
>>> 
>>>      "iss": "https://transmitter.example.com <https://transmitter.example.com/>",
>>> 
>>>      "aud": [ "https://receiver.example.com <https://receiver.example.com/>" ],
>>> 
>>>      "iat": 1458496025,
>>> 
>>>      "event": {
>>> 
>>>        "event_type": "https://secevent.example.com/example_event <https://secevent.example.com/example_event>",
>>> 
>>>        "event_subject": {
>>> 
>>>            "iss": "https://idp.example.com <https://idp.example.com/>",
>>> 
>>>            "sub": "abc123",
>>> 
>>>          },
>>> 
>>>          {
>>> 
>>> On Thu, Dec 7, 2017 at 12:28 AM, Morteza Ansari (moransar) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> +1
>>> 
>>>  
>>> 
>>> From: Id-event <[email-masked] <mailto:[email-masked]>> on behalf of Phil Hunt <[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]>>
>>> www.independentid.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM&s=337h9ahCqEnkyo3wKcMrEVWEEXSZ5HswVurVvXBet9k&e=>
>>> On Dec 5, 2017, at 12:50 PM, Mike Jones <[email-masked] <mailto:[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=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM&s=o3JZgDc6WNNqDqIl_RSgzBmT4KEget2lduea5cfV5fA&e=>
>>>  
>>> 
>>> 
>> 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qCsVU8GSrNishJH840WEp7RRVV5Qyt_dAFLnIxZdXrA&s=hWumbgAlx3vB4z_y8DRi4w6VEh7XVep0LAn9KBC5Ds0&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qCsVU8GSrNishJH840WEp7RRVV5Qyt_dAFLnIxZdXrA&s=hWumbgAlx3vB4z_y8DRi4w6VEh7XVep0LAn9KBC5Ds0&e=>
>

---

From: Nat Sakimura <[email-masked]>
Date: Mon, 11 Dec 2017 23:44:14 +0000

+1

Let us do it in another spec that registers a new claim for alternative
subjects, etc.

On Tue, Dec 12, 2017 at 7:50 AM John Bradley <[email-masked]> wrote:

> Are some of you thinking that we would define set_subject (or some such)
> as a dict and let some other spec define what goes in the dict?
>
> John
>
>
>
>> How is SCIM pointing to the subject? Always using iss+sub? SCIM will
>> never be in the situation where the subject issuer is different from the
>> SET issuer?
>>
>> Again, this thread is not asking for a major change, it is asking to add
>> a claim name that can be used by profiles as an extension point. There is
>> the question of alternative subject identifiers, so some discussion is
>> necessary.
>>
>>
>>>
>>>
>>> Phil
>>>
>>> On Thu, Dec 7, 2017 at 11:54 AM, Mike Jones <[email-masked]
>>> > wrote:
>>>
>>>> especially since some already deployed profiles, such as OpenID
>>>> Connect Back-Channel Logout
>>>> But to be clear, I am strongly opposed to trying to jam this new
>>>> feature still that is still being designed into the already mature SET
>>>> spec, which would certainly unnecessarily significantly delay its
>>>> completion.
>>>>
>>>>
>>>>
>>>>                                                                 -- Mike
>>>>
>>>>
>>>>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 11 Dec 2017 16:10:57 -0800

We keep mixing concerns here. This proposal is to add a claim for a subject
place holder, an extension point. Sure we can split this out to a separate
spec, but if we do that to speed things up then I am not sure if that is
effective. Most implementations will ideally need both specs anyhow.

There is a different thread that suggests a few common formats, but that's
a different topic.

Marius

On Mon, Dec 11, 2017 at 3:44 PM, Nat Sakimura <[email-masked]> wrote:

>>>> Most implementors will have to wait for the event subject claim as
>>>> well, and they will be slowed down even more.
>>>>
>>>>
>>>>>
>>>>>
>>>> How is back-channel affected in either case? It will not use a new
>>>> event subject claim, so it does matter. Everyone else will be affected as
>>>> stated above.
>>>>
>>>>
>>>>>
>>>>>
>>>>> We should not block the SET spec, which is mature, on new work that
>>>>> can and should be decoupled, and is still in its formative stages.
>>>>>
>>>>
>>>>> I think this should be added to the current SET spec and not a
>>>>> separate spec. Yes, it will slow down the SET spec, but that is unavoidable
>>>>> and very necessary. Implementations will have to wait for the subject claim
>>>>> spec anyhow. The real questions speed question is this: will two specs be
>>>>> faster than adding to the existing one? And speed is not the only criteria.

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Dec 2017 00:57:53 +0000

To the contrary, as I see it, it’s mixing independent concerns to try to delay an already mature SET spec for a not yet even designed structured subject claim.  Despite your statements, in fact, many implementations won’t need it.  Backchannel logout doesn’t need it.  Multiple other use cases don’t need it.

I’m great with RISC providing input to a design of such a claim in its own spec once there are implementations using it.  But in fact, RISC is the only use case I’m aware of that might even use such a claim.

That argues for finishing SET and then possibly designing a structured event subject claim once there is implementation and deployment experience with it to inform the design.

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Monday, December 11, 2017 4:11 PM
To: Nat Sakimura <[email-masked]>
Cc: John Bradley <[email-masked]>; William Denniss <[email-masked]>; SecEvent <[email-masked]>; Yaron Sheffer <[email-masked]>; Mike Jones <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending

We keep mixing concerns here. This proposal is to add a claim for a subject place holder, an extension point. Sure we can split this out to a separate spec, but if we do that to speed things up then I am not sure if that is effective. Most implementations will ideally need both specs anyhow.

There is a different thread that suggests a few common formats, but that's a different topic.

Marius

On Mon, Dec 11, 2017 at 3:44 PM, Nat Sakimura <[email-masked]<mailto:[email-masked]>> wrote:
+1

Let us do it in another spec that registers a new claim for alternative subjects, etc.

On Tue, Dec 12, 2017 at 7:50 AM John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
I have a feeling that defining a extendable structured subject may be a never ending task.

John

On Dec 8, 2017, at 5:37 PM, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Dec 8, 2017 at 1:34 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
That is a bit unfair. RISC is as important to me as the rest.

Phil

On Dec 7, 2017, at 8:02 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Dec 7, 2017 at 5:15 PM, Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
Scim and backchannel do not need it. They would like to move on.

Phil

On Dec 7, 2017, at 4:56 PM, Marius Scurtescu <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Dec 7, 2017 at 11:54 AM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
Marius – you say that “it will slow down the SET spec, but that is unavoidable and very necessary. Implementations will have to wait for the subject claim spec anyhow.”

                                                       -- Mike

From: Marius Scurtescu [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, December 7, 2017 11:49 AM
To: Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>>
Cc: Phil Hunt <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>

{

Marius

Cheers,
Morteza

I agree with Mike.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.independentid.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM&s=337h9ahCqEnkyo3wKcMrEVWEEXSZ5HswVurVvXBet9k&e=>
[email-masked]<mailto:[email-masked]>

                                                                -- Mike

-----Original Message-----
From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Sunday, December 3, 2017 9:39 AM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: [Id-event] Consensus :: Event Subject Claim - resending

_______________________________________________
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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=ZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM&s=o3JZgDc6WNNqDqIl_RSgzBmT4KEget2lduea5cfV5fA&e=>

Nat Sakimura

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 11 Dec 2017 18:19:04 -0800

Mike, this very same issue came up several months ago (maybe even a year),
your answer was to move this to a profile. Had we considered this issue at
that time then we would not be worried about delaying SET now.

Other than backchannel logout, can you provide one more example where this
is actually not needed? Are we creating a spec that is good enough for
backchannel logout and nothing else? Because consistently that is the
reason you provide.

There is nothing special about RISC asking for a subject claim, here are
some other use cases (and all of them came up before):
- SET issuer and subject issuer are different (there is a clear use case
for that)
- OAuth profile (token and client related events)
- SCIM
- RISC SET
- RISC add/remove subject API

Asking each profile to independently solve this same issue over and over
again is not reasonable. And it raises the question of what is the value
provided by SET (this is also a question that keeps coming up)?

You keep claiming that the SET spec is mature. Implementors are telling you
it is not. Why do you completely ignore that feedback?

Marius

On Mon, Dec 11, 2017 at 4:57 PM, Mike Jones <[email-masked]>
wrote:

> To the contrary, as I see it, it’s mixing independent concerns to try to
> delay an already mature SET spec for a not yet even designed structured
> subject claim.  Despite your statements, in fact, many implementations
> won’t need it.  Backchannel logout doesn’t need it.  Multiple other use
> cases don’t need it.
>
>
>
> I’m great with RISC providing input to a design of such a claim in its own
> spec once there are implementations using it.  But in fact, RISC is the
> only use case I’m aware of that might even use such a claim.
>
>
>
> That argues for finishing SET and then possibly designing a structured
> event subject claim once there is implementation and deployment experience
> with it to inform the design.
>
>
>
>                                                        -- Mike
>
>
>
> *Sent:* Monday, December 11, 2017 4:11 PM
> *To:* Nat Sakimura <[email-masked]>
> *Cc:* John Bradley <[email-masked]>; William Denniss <
> [email-masked]>; SecEvent <[email-masked]>; Yaron Sheffer <
> [email-masked]>; Mike Jones <[email-masked]>; Morteza
> Ansari (moransar) <[email-masked]>; Phil Hunt <[email-masked]>
>
> We keep mixing concerns here. This proposal is to add a claim for a
> subject place holder, an extension point. Sure we can split this out to a
> separate spec, but if we do that to speed things up then I am not sure if
> that is effective. Most implementations will ideally need both specs anyhow.
>
>
>

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 11 Dec 2017 18:31:37 -0800

> That is a bit unfair. RISC is as important to me as the rest.

Well, then let's look at all the feedback and let's try to make a generally
useful spec.

The consistent reason to reject any and all suggestions for changes (going
on for months) is "works for backchannel logout, let's move on". Do you
find that reasonable?

> You have commented you want pilots by end of year. That is what we are

Yes, I want pilots and a final spec as soon as possible, but I also want a
good spec and a reasonable working group where we can all contribute and
have a healthy discussion. The current state is that almost everything is
rejected (because, you know, backchannel logout does not need it).

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 14 Dec 2017 00:05:58 +0000

I’m fine working on a structured claim for defined use cases that need this feature, but it should be in a new specification and delay the completion of SET.

From: Id-event [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Monday, December 11, 2017 3:44 PM
To: John Bradley <[email-masked]>
Cc: Marius Scurtescu <[email-masked]>; SecEvent <[email-masked]>; Yaron Sheffer <[email-masked]>; Mike Jones <[email-masked]>; William Denniss <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending

+1

John

Phil

Phil

                                                       -- Mike

{
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "iss": "https://transmitter.example.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftransmitter.example.com%2F&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=XL%2FZ9pdZ5grKvPvDcOF5NMTShAXrqqCievBdGwKq1TI%3D&reserved=0>",
     "aud": [ "https://receiver.example.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freceiver.example.com%2F&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=Ejln4QymstdOQr6fiA0MzxoXiQi5mqdaKDl6FPRYTf8%3D&reserved=0>" ],
     "iat": 1458496025,
     "event": {
       "event_type": "https://secevent.example.com/example_event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecevent.example.com%2Fexample_event&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=8fTRzvqSscLnCu%2BJwV4fe5EcgQsaXq4BsnLGgRLSK2E%3D&reserved=0>",
       "event_subject": {
         "identifier_type": "urn:ietf:params:secevent:subject:email",
         "email": "[email-masked]<mailto:[email-masked]>"
       },
       "event_subject_alt": [
         {
           "identifier_type": "urn:ietf:params:secevent:subject:connect",
           "iss": "https://idp.example.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fidp.example.com%2F&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=wVm9dXBJicnhFZlZI54Al%2Bja97ovCFewuPEPCooY9uI%3D&reserved=0>",
           "sub": "abc123",
         },
         {
           "identifier_type": "urn:ietf:params:secevent:subject:phone",
           "phone_number": "+40-123-456-789",
         },
       ],
       "event_time": 1458492425,
       "claim_1": "foo",
       "claim_2": "bar"
     }
   }

Marius

Cheers,
Morteza

I agree with Mike.

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__www.independentid.com%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM%26s%3D337h9ahCqEnkyo3wKcMrEVWEEXSZ5HswVurVvXBet9k%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=CNZ277RbPRGg4StwVNDTAET%2FmulZ5akOLV7vn8vakGM%3D&reserved=0>
[email-masked]<mailto:[email-masked]>

I'm fine with the working group deciding to work on an optional event subject claim to be used by some profiles, should people want to do that, provided that doing so does not delay completion of the SET spec.  If pursued, this work should be in a separate specification, with the defined claim being registered in the IANA JWT Claims Registry<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.iana.org_assignments_jwt_jwt.xhtml-23claims%26d%3DDwMFAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DaaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps%26s%3Dav4hHqgyAvaRXI2KW6bkEG3BGLGz_h_LyoqavIRYfHg%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=6Ll3Cc%2FLiqU6G0AYjfqR6zH5mn%2Bmfn%2FXGTIwcg6bcMQ%3D&reserved=0>- especially since some already deployed profiles, such as OpenID Connect Back-Channel Logout<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__openid.net_specs_openid-2Dconnect-2Dbackchannel-2D1-5F0.html-23LogoutToken%26d%3DDwMFAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DaaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps%26s%3D1JCW4kxfnjPG-TL2O_svnmaKgt3oIQDMddR09ByNql0%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=%2FllZjyb4R9NMMkf5m3TNqsy0uQiNvR%2BCVwI2IXENgbw%3D&reserved=0> and I believe others, don't need it.

                                                                -- Mike

-----Original Message-----
From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Sunday, December 3, 2017 9:39 AM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: [Id-event] Consensus :: Event Subject Claim - resending

The current draftdraft-ietf-secevent-token-03 <https://tools.ietf.org/html/draft-ietf-secevent-token-03<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__tools.ietf.org_html_draft-2Dietf-2Dsecevent-2Dtoken-2D03%26d%3DDwMFAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DaaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps%26s%3DcOFNVfa2dkD5DMrxaPJNWbf6ePHRdWkk8LCkcMh4ZUI%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=by1vihkSRrLqEleI5oeuQe3iKHXIqJcWlmmkzEMn2PA%3D&reserved=0>>defines
the/sub/claim as an optional string or URI, with semantics left to the profile. This claim is placed in the SET envelope. No "subject" claim is defined inside the/event/object, which means that profiles are free to define such claims as they see fit.

We will track results here:
https://github.com/IETF-SecEvent/Drafts/issues/2<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_IETF-2DSecEvent_Drafts_issues_2%26d%3DDwMFAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DaaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps%26s%3DKR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=hXLnPDLQwPKsge6zrm2XNXeA5jWzkEnDlXMpXmAcYEI%3D&reserved=0>
<https://github.com/IETF-SecEvent/Drafts/issues/2<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_IETF-2DSecEvent_Drafts_issues_2%26d%3DDwMFAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DaaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps%26s%3DKR9ZS06-A2FnJEURs1owDpuj_s_BVWLcUJObCaxUrhs%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=hXLnPDLQwPKsge6zrm2XNXeA5jWzkEnDlXMpXmAcYEI%3D&reserved=0>>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMFAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DaaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps%26s%3DUnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=kj3y%2FZ4zD8GbxwnedGFmXYQPQO1hlyAjJc50ac1aQWk%3D&reserved=0>
_______________________________________________
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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=aaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps&s=UnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo&e=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DaaWzYOZ8Vr8XdQB6u0dfVLnXSIhCmL99jQuVQvbX_ps%26s%3DUnJQSxeu8QPyD8WdRw2SdMJpIxbhktv3H13HpVmtuAo%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=PktCOV6XR7WNE7bh6LdYaJ2SrCKPClVNA%2B7AvOQuwjk%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwMFaQ%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DZHZu3ZUvimU1ZA6RrQtYoCsRz2p1S3Be04ExL_-SQyM%26s%3Do3JZgDc6WNNqDqIl_RSgzBmT4KEget2lduea5cfV5fA%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=3S5P%2Fg2uaDxf7ls%2F3m3MhtZHMKBxyJu2h4JnVaZnRPs%3D&reserved=0>

_______________________________________________
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=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=qCsVU8GSrNishJH840WEp7RRVV5Qyt_dAFLnIxZdXrA&s=hWumbgAlx3vB4z_y8DRi4w6VEh7XVep0LAn9KBC5Ds0&e=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__www.ietf.org_mailman_listinfo_id-2Devent%26d%3DDwICAg%26c%3DRoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE%26r%3Dna5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA%26m%3DqCsVU8GSrNishJH840WEp7RRVV5Qyt_dAFLnIxZdXrA%26s%3DhWumbgAlx3vB4z_y8DRi4w6VEh7XVep0LAn9KBC5Ds0%26e%3D&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=G%2FYuSPnfHZ2E1T3Xh%2F3rRIWF1s5N3Exl1HvMvGeECnc%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=uq8fQO2cuoIwVEB%2BS9RnqZLsvEuUNKisOftxkQtWScs%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=uq8fQO2cuoIwVEB%2BS9RnqZLsvEuUNKisOftxkQtWScs%3D&reserved=0>

_______________________________________________
Id-event mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/id-event<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fid-event&data=04%7C01%7Ctonynad%40microsoft.com%7C797b390730d443b2e4b308d540f122ed%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636486326785754138%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=uq8fQO2cuoIwVEB%2BS9RnqZLsvEuUNKisOftxkQtWScs%3D&reserved=0>
--

Nat Sakimura

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 14 Dec 2017 00:12:05 +0000

Sorry I meant to say *NOT DELAY*

From: Anthony Nadalin
Sent: Wednesday, December 13, 2017 4:06 PM
To: 'Nat Sakimura' <[email-masked]>; John Bradley <[email-masked]>
Cc: Marius Scurtescu <[email-masked]>; SecEvent <[email-masked]>; Yaron Sheffer <[email-masked]>; Mike Jones <[email-masked]>; William Denniss <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; Phil Hunt <[email-masked]>
Subject: RE: [Id-event] Consensus :: Event Subject Claim - resending

From: Id-event [mailto:[email-masked]] On Behalf Of Nat Sakimura
Sent: Monday, December 11, 2017 3:44 PM
To: John Bradley <[email-masked]<mailto:[email-masked]>>
Cc: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>; SecEvent <[email-masked]<mailto:[email-masked]>>; Yaron Sheffer <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>; William Denniss <[email-masked]<mailto:[email-masked]>>; Morteza Ansari (moransar) <[email-masked]<mailto:[email-masked]>>; Phil Hunt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending

+1

John

Phil

Phil

                                                       -- Mike

{

Marius

Cheers,
Morteza

I agree with Mike.

Phil

                                                                -- Mike

-----Original Message-----
From: Id-event [mailto:[email-masked]] On Behalf Of Yaron Sheffer
Sent: Sunday, December 3, 2017 9:39 AM
To: SecEvent <[email-masked]<mailto:[email-masked]>>
Subject: [Id-event] Consensus :: Event Subject Claim - resending

Nat Sakimura

---

From: "M.Lizar@OCG" <[email-masked]>
Date: Thu, 14 Dec 2017 16:12:13 -0500

+1 - We would like to discourage delays in the completion of SETs to add a structured event claim.  The Consent Receipt v1.1 <https://kantarainitiative.org/confluence/download/attachments/76447870/Consent%20Receipt%20Specification%201_1_0%20DRAFT%206.docx?version=1&modificationDate=1511151270000&api=v2> that is now finally in a 45 Day public IPR review at the Kantara initiative is aimed  at providing the content and format semantics for privacy transparency and compliance.   Other specs like the  COEL <http://docs.oasis-open.org/coel/COEL/v1.0/csprd02/COEL-v1.0-csprd02.pdf> from OASIS, which use this same format, have now also just gone into 45 day public review. 

For us, its important to get this spec stable before the new GDPR laws become enforced in May

Mark 

> On 8 Dec 2017, at 15:37, William Denniss <[email-masked]> wrote:
>

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Thu, 14 Dec 2017 22:33:02 +0000

Neither of those documents makes any reference to SET. How do they depend on its finalization?

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of "M.Lizar@OCG" <[email-masked]>
Date: Thursday, December 14, 2017 at 1:14 PM
To: William Denniss <[email-masked]>
Cc: Marius Scurtescu <[email-masked]>, SecEvent <[email-masked]>, Yaron Sheffer <[email-masked]>, Mike Jones <[email-masked]>, "Morteza Ansari (moransar)" <[email-masked]>, Phil Hunt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending

+1 - We would like to discourage delays in the completion of SETs to add a structured event claim.  The Consent Receipt v1.1<https://kantarainitiative.org/confluence/download/attachments/76447870/Consent%20Receipt%20Specification%201_1_0%20DRAFT%206.docx?version=1&modificationDate=1511151270000&api=v2> that is now finally in a 45 Day public IPR review at the Kantara initiative is aimed  at providing the content and format semantics for privacy transparency and compliance.   Other specs like the  COEL<http://docs.oasis-open.org/coel/COEL/v1.0/csprd02/COEL-v1.0-csprd02.pdf> from OASIS, which use this same format, have now also just gone into 45 day public review.

Mark

On 8 Dec 2017, at 15:37, William Denniss <[email-masked]<mailto:[email-masked]>> wrote:

Phil

Phil

                                                       -- Mike

{

Marius

Cheers,
Morteza

I agree with Mike.

Phil

                                                                -- Mike

---

From: "M.Lizar@OCG" <[email-masked]>
Date: Thu, 14 Dec 2017 19:47:24 -0500

Consent receipts would like to use SETs once they're stable. 

Mark

> On 14 Dec 2017, at 17:33, Richard Backman, Annabelle <[email-masked]> wrote:
> 
>> On 8 Dec 2017, at 15:37, William Denniss <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Marius Scurtescu <[email-masked]>
Date: Thu, 14 Dec 2017 17:03:56 -0800

Mark, this thread tackles a potential event subject claim and you mention
structured event claim. I assume you meant structured subject claim.

Do you understand the current limitations of how subjects can be expressed?
Are you sure that Consent Receipts can deal with these limitations? If not,
then rushing the current SET and then working on a separate draft just for
subject claims will overall result in an even longer delay. More than that,
Consent Receipts and most other profiles will not be able to use only the
SET spec, they will also need the delivery spec and the management api
specs and at least the management api spec also has a dependency on a
subject claim. So again, rushing SET will not buy us much.

The only profile that depends only on SET and apparently does not care
about a subject claim is back-channel logout. I understand that Mike wants
to move forward but as an author I think he should take into consideration
all feedback and all use cases.

We all want stable specs as soon as possible, but we want solid functional
specs that cover a large number of use cases.

Marius

On Thu, Dec 14, 2017 at 4:47 PM, M.Lizar@OCG <[email-masked]>
wrote:

> *From: *Id-event <[email-masked]> on behalf of "M.Lizar@OCG" <
> [email-masked]>
> *Date: *Thursday, December 14, 2017 at 1:14 PM
> *To: *William Denniss <[email-masked]>
> *Cc: *Marius Scurtescu <[email-masked]>, SecEvent <
> [email-masked]>, Yaron Sheffer <[email-masked]>, Mike Jones <
> [email-masked]>, "Morteza Ansari (moransar)" <
> [email-masked]>, Phil Hunt <[email-masked]>
> +1 - We would like to discourage delays in the completion of SETs to add a
> structured event claim.  The Consent Receipt v1.1
> <https://kantarainitiative.org/confluence/download/attachments/76447870/Consent%20Receipt%20Specification%201_1_0%20DRAFT%206.docx?version=1&modificationDate=1511151270000&api=v2> that
> is now finally in a 45 Day public IPR review at the Kantara initiative is
> aimed  at providing the content and format semantics
> for privacy transparency and compliance.   Other specs like the  COEL
> <http://docs.oasis-open.org/coel/COEL/v1.0/csprd02/COEL-v1.0-csprd02.pdf> from
> OASIS, which use this same format, have now also just gone into 45 day
> public review.
>
>

---

From: Mike Jones <[email-masked]>
Date: Fri, 15 Dec 2017 02:05:09 +0000

Marius, Mark already wrote in another of the consensus calls: “The spec works well for the consent a privacy syntax use cases we are aware of.”  I’m not sure why you’re doubting him now.

The consent receipt has a string-valued “piiPrincipalId” claim, which could either be used in the SET directly or placed in a “sub” claim.  Frankly, I don’t see any reason why consent receipts wouldn’t continue to use the same claims to identify their subjects that they do today.  (But Mark is authoritative on this subject – not me.)

                                                       -- Mike

P.S.  Marius, I hope you will refrain from personal attacks in the future.  I *have* been listening to multiple developers and deployers with independent use cases, including RISC developers, as have other working group members.  Please try to focus discussion in productive ways on use cases, business value, engineering tradeoffs, and feedback from actual deployments.  I don’t want anyone to feel any ill will at the end of this process, simply because people may have disagreed about the best path forward in the short term.  Healthy disagreement about engineering and schedule tradeoffs is normal and listening to one another helps us all get to a better outcome than would have otherwise been achieved.

From: Marius Scurtescu [mailto:[email-masked]]
Sent: Thursday, December 14, 2017 5:04 PM
To: M.Lizar@OCG <[email-masked]>
Cc: Richard Backman, Annabelle <[email-masked]>; William Denniss <[email-masked]>; SecEvent <[email-masked]>; Yaron Sheffer <[email-masked]>; Mike Jones <[email-masked]>; Morteza Ansari (moransar) <[email-masked]>; Phil Hunt <[email-masked]>
Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending

Mark, this thread tackles a potential event subject claim and you mention structured event claim. I assume you meant structured subject claim.

Do you understand the current limitations of how subjects can be expressed? Are you sure that Consent Receipts can deal with these limitations? If not, then rushing the current SET and then working on a separate draft just for subject claims will overall result in an even longer delay. More than that, Consent Receipts and most other profiles will not be able to use only the SET spec, they will also need the delivery spec and the management api specs and at least the management api spec also has a dependency on a subject claim. So again, rushing SET will not buy us much.

The only profile that depends only on SET and apparently does not care about a subject claim is back-channel logout. I understand that Mike wants to move forward but as an author I think he should take into consideration all feedback and all use cases.

We all want stable specs as soon as possible, but we want solid functional specs that cover a large number of use cases.

Marius

On Thu, Dec 14, 2017 at 4:47 PM, M.Lizar@OCG<mailto:M.Lizar@OCG> <[email-masked]<mailto:[email-masked]>> wrote:
Consent receipts would like to use SETs once they're stable.

Mark

On 14 Dec 2017, at 17:33, Richard Backman, Annabelle <[email-masked]<mailto:[email-masked]>> wrote:

From: Id-event <[email-masked]<mailto:[email-masked]>> on behalf of "M.Lizar@OCG<mailto:M.Lizar@OCG>" <[email-masked]<mailto:[email-masked]>>
Date: Thursday, December 14, 2017 at 1:14 PM
To: William Denniss <[email-masked]<mailto:[email-masked]>>
Cc: Marius Scurtescu <[email-masked]<mailto:[email-masked]>>, SecEvent <[email-masked]<mailto:[email-masked]>>, Yaron Sheffer <[email-masked]<mailto:[email-masked]>>, Mike Jones <[email-masked]<mailto:[email-masked]>>, "Morteza Ansari (moransar)" <[email-masked]<mailto:[email-masked]>>, Phil Hunt <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Id-event] Consensus :: Event Subject Claim - resending

Mark

Phil

Phil

                                                       -- Mike

{

Marius

Cheers,
Morteza

I agree with Mike.

Phil

                                                                -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Thu, 14 Dec 2017 20:10:56 -0800

Marius

What limitations on subject? 

Profiles are free to do what they want:
A) define their own claims to be embedded in the payload
And/Or
B) register new jwt claims to use in the top level of the jwt structure (like sub is). 

Mark's consent event is fine to use the current draft without a standard subject. 

Remember a SET is a profile of JWT and inherits its features. 

Phil

> On Dec 14, 2017, at 5:03 PM, Marius Scurtescu <[email-masked]> wrote:
> 
>> On Thu, Dec 14, 2017 at 4:47 PM, M.Lizar@OCG <[email-masked]> wrote:
>>> +1 - We would like to discourage delays in the completion of SETs to add a structured event claim.  The Consent Receipt v1.1 that is now finally in a 45 Day public IPR review at the Kantara initiative is aimed  at providing the content and format semantics for privacy transparency and compliance.   Other specs like the  COEL from OASIS, which use this same format, have now also just gone into 45 day public review. 
>>> 
>>>

---

From: Adam Dawes <[email-masked]>
Date: Thu, 14 Dec 2017 22:30:03 -0800

> What limitations on subject?

Limitations on subject is perhaps the wrong wording. I would phrase it as
encouraging fragmentation of subjects across many profiles which will make
interop more difficult and the production of broadly useful libraries
unlikely. SET shouldn't mandate subjects, but the need for subjects is
going to span multiple profiles so a common base definition will greatly
aid interop and the expansion of profiles.

> Do you understand the current limitations of how subjects can be
> expressed? Are you sure that Consent Receipts can deal with these
> limitations? If not, then rushing the current SET and then working on a
> separate draft just for subject claims will overall result in an even
> longer delay. More than that, Consent Receipts and most other profiles will
> not be able to use only the SET spec, they will also need the delivery spec
> and the management api specs and at least the management api spec also has
> a dependency on a subject claim. So again, rushing SET will not buy us much.
>
> On Thu, Dec 14, 2017 at 4:47 PM, M.Lizar@OCG <[email-masked]
> > wrote:
>
>> +1 - We would like to discourage delays in the completion of SETs to add
>> a structured event claim.  The Consent Receipt v1.1
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__kantarainitiative.org_confluence_download_attachments_76447870_Consent-2520Receipt-2520Specification-25201-5F1-5F0-2520DRAFT-25206.docx-3Fversion-3D1-26modificationDate-3D1511151270000-26api-3Dv2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=LGnccpkFKwALFB85NCQ5HNf6Myyay6mjrH13RWOYPXY&s=0yZpnjnkbV0FfO8yF5ZZaA44ftx1AZ7Suk-HHk7C9mg&e=> that
>> is now finally in a 45 Day public IPR review at the Kantara initiative
>> is aimed  at providing the content and format semantics
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.oasis-2Dopen.org_coel_COEL_v1.0_csprd02_COEL-2Dv1.0-2Dcsprd02.pdf&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=LGnccpkFKwALFB85NCQ5HNf6Myyay6mjrH13RWOYPXY&s=VrqjKwFEBedkl51YIQ77AA5QBM8jwWZAH8NbRbQ7sTs&e=> from
>> PkAI1aLcLN4KZNA&m=qCsVU8GSrNishJH840WEp7RRVV5Qyt_
>> dAFLnIxZdXrA&s=hWumbgAlx3vB4z_y8DRi4w6VEh7XVep0LAn9KBC5Ds0&e=
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=LGnccpkFKwALFB85NCQ5HNf6Myyay6mjrH13RWOYPXY&s=f5HX7VMkSyBFPZVYt-hRP_N7CvU3ghtTO9tZkyg5bA4&e=>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=LGnccpkFKwALFB85NCQ5HNf6Myyay6mjrH13RWOYPXY&s=f5HX7VMkSyBFPZVYt-hRP_N7CvU3ghtTO9tZkyg5bA4&e=>
>>
>>
>>
>>
>>
>

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

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 15 Dec 2017 09:07:23 -0800

On Thu, Dec 14, 2017 at 6:05 PM, Mike Jones <[email-masked]>
wrote:

> Marius, Mark already wrote in another of the consensus calls: “The spec
> works well for the consent a privacy syntax use cases we are aware of.”
> I’m not sure why you’re doubting him now.
>

I am not doubting Mark, I want to understand his use cases.

>
> The consent receipt has a string-valued “piiPrincipalId” claim, which
> could either be used in the SET directly or placed in a “sub” claim.
> Frankly, I don’t see any reason why consent receipts wouldn’t continue to
> use the same claims to identify their subjects that they do today.  (But
> Mark is authoritative on this subject – not me.)
>

OK, so let's hear from Mark.

>
>
>                                                        -- Mike
>
>
>
> P.S.  Marius, I hope you will refrain from personal attacks in the future.
>

These are not personal attacks Mike, I am sorry you feel like that. I am
frustrated because I feel that we don't have a functioning working group.

  I **have** been listening to multiple developers and deployers with
> independent use cases, including RISC developers, as have other working
> group members.
>

Maybe you have. What I can say is that RISC is the only profile that
presented a detailed use case document to drive requirements. It's concerns
and use cases seem to be ignored constantly for a long time. Just saying
how the situation looks from my perspective.

>   Please try to focus discussion in productive ways on use cases, business
> value, engineering tradeoffs, and feedback from actual deployments.  I
> don’t want anyone to feel any ill will at the end of this process, simply
> because people may have disagreed about the best path forward in the short
> term.  Healthy disagreement about engineering and schedule tradeoffs is
> normal and listening to one another helps us all get to a better outcome
> than would have otherwise been achieved.
>

Perfect, we are on the same page.

With that in mind, can I ask you to spell out reasons in details? It helps
me and others understand your reasoning and I will feel heard.

Also, I want to acknowledge that you do have a difficult job and I do
appreciate that you want to keep the spec stable. I think it is very
reasonable to push back on requests for major changes, but at the same time
it is reasonable at times to take them into consideration.

> *Sent:* Thursday, December 14, 2017 5:04 PM
> *To:* M.Lizar@OCG <[email-masked]>
> *Cc:* Richard Backman, Annabelle <[email-masked]>; William Denniss <

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Dec 2017 10:19:55 -0800

Comments in line. 

Phil

> On Dec 15, 2017, at 9:07 AM, Marius Scurtescu <[email-masked]> wrote:
> 
>> On Thu, Dec 14, 2017 at 6:05 PM, Mike Jones <[email-masked]> wrote:

> These are not personal attacks Mike, I am sorry you feel like that. I am frustrated because I feel that we don't have a functioning working group.
> 
>>   I *have* been listening to multiple developers and deployers with independent use cases, including RISC developers, as have other working group members.
>> 
> 
> Maybe you have. What I can say is that RISC is the only profile that presented a detailed use case document to drive requirements. It's concerns and use cases seem to be ignored constantly for a long time. Just saying how the situation looks from my perspective.

<ph>. This is not true. Backchannel logout has implementers and clear draft published. 

SCIM published its use cases to this group and also has an ID for it's events (expired). 

RISC has no published wg materials of its own. 

If we want to discuss non-functional, part of the problem is the presumption that RISC itself has consensus on its requirements. We do not because again risc has not published. I know because I am a sponsoring member participant. 
> 
>  
>>   Please try to focus discussion in productive ways on use cases, business value, engineering tradeoffs, and feedback from actual deployments.  I don’t want anyone to feel any ill will at the end of this process, simply because people may have disagreed about the best path forward in the short term.  Healthy disagreement about engineering and schedule tradeoffs is normal and listening to one another helps us all get to a better outcome than would have otherwise been achieved.
>> 
> 
> With that in mind, can I ask you to spell out reasons in details? It helps me and others understand your reasoning and I will feel heard.
<ph> i believe we have at length
> 
> Also, I want to acknowledge that you do have a difficult job and I do appreciate that you want to keep the spec stable. I think it is very reasonable to push back on requests for major changes, but at the same time it is reasonable at times to take them into consideration.

<ph> I remained surprised the chairs found relevance to re-open the issue. Had you considered https://tools.ietf.org/html/draft-hunt-idevent-token-00 you would note that single event is where this work began. 

If we make this change we will have gone in circles without clear justification and have failed to move forward. IMO, this would compromise the consensus process given that most people want to finish. 

Also why are you strongly dismissing running code? This is a core principle of the ietf. The new proposal has no implementation nor evidence it addresses the so-called ambiguity issue.  See my other email. 

We have worked well in the past. I hope you don't wish to kill this effort with your passion. 

If the draft does go forward it will be rough consensus. I regret that.

---

From: Marius Scurtescu <[email-masked]>
Date: Fri, 15 Dec 2017 14:28:10 -0800

> <ph>. This is not true. Backchannel logout has implementers and clear

Happy to look a use case document for back-channel logout. For what I
understand it is a very simple use case. The constant argument I hear is
that everything works for back-channel logout, and while that is a good
thing I also don't think it is enough.

>From what I remember the SCIM use cases were very high level, which makes
them hard to drive any requirements. But I can be wrong, can you please
point to the latest doc?

> RISC has no published wg materials of its own.

What's that supposed to mean? RISC presented detailed use cases and they
are tracked in an I-D.

>
> If we want to discuss non-functional, part of the problem is the
> presumption that RISC itself has consensus on its requirements. We do not
> because again risc has not published. I know because I am a sponsoring
> member participant.
>

Not published what and where? Yes, of course it is work in progress and
there are lots of open issues. Not sure where are you going with this.

>
>
>
>>   Please try to focus discussion in productive ways on use cases,
>> business value, engineering tradeoffs, and feedback from actual
>> deployments.  I don’t want anyone to feel any ill will at the end of this
>> process, simply because people may have disagreed about the best path
>> forward in the short term.  Healthy disagreement about engineering and
>> schedule tradeoffs is normal and listening to one another helps us all get
>> to a better outcome than would have otherwise been achieved.
>>
>

>From where I stand what I see is answers like "works for back-channel
logout" or "great reasons". Please don't take this personally, but use it
as feedback to understand why we might have a disconnect.

> <ph> I remained surprised the chairs found relevance to re-open the issue.
> Had you considered https://tools.ietf.org/html/draft-hunt-idevent-token-00 you
> would note that single event is where this work began.
>
> If we make this change we will have gone in circles without clear
> justification and have failed to move forward. IMO, this would compromise
> the consensus process given that most people want to finish.
>
> Also why are you strongly dismissing running code? This is a core
> principle of the ietf. The new proposal has no implementation nor evidence
> it addresses the so-called ambiguity issue.  See my other email.
>

I am providing feedback as an early implementor, so yes, I do care about
running code. I kept saying this over and over, not sure why are you
lecturing me on this subject.

> We have worked well in the past. I hope you don't wish to kill this effort

Same here. Not trying to kill anything, hoping for a working group where
there is real collaboration. I understand that you see it different, but
the way I see it is that there is no collaboration and that most efforts to
improve the specs are constantly blocked.

> If the draft does go forward it will be rough consensus. I regret that.

Not sure I understand?

>> [email-masked]>; Mike Jones <[email-masked]>;
>> Morteza Ansari (moransar) <[email-masked]>; Phil Hunt <
>> [email-masked]>
>>
>> We all want stable specs as soon as possible, but we want solid
>> functional specs that cover a large number of use cases.
>>
>>
>>
>>
>> Marius
>>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__kantarainitiative.org_confluence_download_attachments_76447870_Consent-2520Receipt-2520Specification-25201-5F1-5F0-2520DRAFT-25206.docx-3Fversion-3D1-26modificationDate-3D1511151270000-26api-3Dv2&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4wH1gymoEq326ZCD687i7fB5qwH-VLvczq8pAdkoRMY&s=PPhowssGLzzU4Dhl21Ao1B11pt25VrdE5V3GBmemdhw&e=> that
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.oasis-2Dopen.org_coel_COEL_v1.0_csprd02_COEL-2Dv1.0-2Dcsprd02.pdf&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4wH1gymoEq326ZCD687i7fB5qwH-VLvczq8pAdkoRMY&s=Q-OouVtbxlEv3EzV5l9cLfwo4aOtwEbcsBi0UGRZQUI&e=> from
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4wH1gymoEq326ZCD687i7fB5qwH-VLvczq8pAdkoRMY&s=ORE8sYOjURtA5iE1Sm2WvJwile2FMTPSvsJPzhvre8M&e=>
>>
>>
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4wH1gymoEq326ZCD687i7fB5qwH-VLvczq8pAdkoRMY&s=ORE8sYOjURtA5iE1Sm2WvJwile2FMTPSvsJPzhvre8M&e=>
>>
>>
>>
>>
>>
>>
>>
>
>

---

From: Luke Camery <[email-masked]>
Date: Mon, 18 Dec 2017 22:11:47 +0000

The arguments on this thread seem to focus around the delay that adding a
subject claim will cause. This seems illogical to me because no profiles,
let alone running code, can be finalized until this question is answered.
We're asking to do this work *once* across all profiles rather than *n
times*. This seems more likely to expedite than delay. In addition, the
management API will be delayed until the subject claim takes shape at
whatever level (profile, SET, or somewhere in between) meaning that the
blocking dependency still exists.

We have as much interest as anyone in getting this out the door. Google has
several engineers working on implementation and we cannot finish
implementation without a clear idea for subject. Throwing SET over the
fence without subject doesn't accomplish this work, it just kicks the can
down the road.

On Fri, Dec 15, 2017 at 2:28 PM Marius Scurtescu <[email-masked]>
wrote:

>> With that in mind, can I ask you to spell out reasons in details? It
>> helps me and others understand your reasoning and I will feel heard.
>>
>> <ph> I remained surprised the chairs found relevance to re-open the
>> issue. Had you considered
>> https://tools.ietf.org/html/draft-hunt-idevent-token-00 you would note
>> that single event is where this work began.
>>
>>> *Cc:* Richard Backman, Annabelle <[email-masked]>; William Denniss
>>> <[email-masked]>; SecEvent <[email-masked]>; Yaron Sheffer <
>>> Mark, this thread tackles a potential event subject claim and you
>>> mention structured event claim. I assume you meant structured subject claim.
>>>
>>>
>>>
>>> *From: *Id-event <[email-masked]> on behalf of "M.Lizar@OCG"
>>> <[email-masked]>
>>> subject in the event payload as they see fit. The existing text reads well
>>> to me.
>>>
>>>
>>>

-- 

*  •  **Luke Camery*
*  •  *Associate Product Manager
*  •  *Federated Identity