Subject: [Id-event] Thoughts on Syntax from today's meeting

From: Justin Richer <[email-masked]>
Date: Mon, 13 Nov 2017 13:21:22 -0500

I wanted to take a few moments to get down on virtual-paper some thoughts 
about the syntax and semantics of a SET from today's meeting. Originally, 
the event snytax that we brought to the table from the Consent Receipts 
working group in Kantara was very explicitly a single event being 
described. When RISC, OIDC sessions, and eventually SCIM came to the 
conersation, the group decided to try out a way to express multiple aspects 
of a single event in a single token. While I still agree with this 
principle, I can see now that it's too much of a temptation to express 
either multiple events or bend around the semantics in ways that could 
cause a lot of confusion. I now think that we should collapse the syntax as 
Annabelle has suggested and go even further to specify what can go where. 
To wit, SET payload profiles should only ever touch the things inside the 
event object. So I'm proposing that we do something like this:

{
  iss: <-- string representing the issuer of the SET itself
  sub: <-- string representing the subject of the SET from the  view of the 
issuer (if known), no format assumed
  iat: <-- timestamp of when the SET Was created, not to be confused with 
the event time
  aud: <-- array or string repreesnting the recipients of this SET, from 
the view of the issuer of the sET
  exp: <-- timestamp of when the SET shouldn't be processed anymore
  event: { <-- object for the event itself, SET profiles do all of their 
definitions in here
     toe: <-- timestamp of the event, if known; if not present, event time 
is unknown
     iss: <-- issuer namespace for the subject of this event, as known by 
the recipient
     sub: <-- subject of the event, as known by the recipient, namespaced 
by event.iss
     txn: <-- transaction identifier for tying multiple events together
     event_type: <-- URI representing this event's type, must be understood 
by recipient (who can do a string match), can define other additional 
fields and their semantics
  }
}

And to Leif's point, to have a group event we would do:

event: {
   event_type: urn:ietf:secevent:event_group
   <any event attributes that are common to the whole set, like txn, toe, 
sub, etc>
   events: [  <-- array of event objects with the semantics of the regular 
event object, taken all at once; can re-use any of the root event elements 
defined in SET but must not repeat any in the root event's common attributes
    ]
}

Event groups create some interop issues, as you need to have clients that 
can handle events in a group as well as on their own. But with the way 
people were describing event groups today, I think that's actually a good 
thing -- it would force recognition of the associated nature of all the 
components. If you get an event group, you need to understand everything in 
the group. No primary/secondary, no pritical fields -- all or nothing.

 Yes this is a change from current syntax and semantics, but to me it feels 
like a return to the consent receipt part of the roots.

 -- Justin

---

From: Phil Hunt <[email-masked]>
Date: Tue, 14 Nov 2017 10:35:40 +0800

How do you propose to handle extensions of event uris?

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>
> On Nov 14, 2017, at 2:21 AM, Justin Richer <[email-masked]> wrote:
> 
> I wanted to take a few moments to get down on virtual-paper some thoughts about the syntax and semantics of a SET from today's meeting. Originally, the event snytax that we brought to the table from the Consent Receipts working group in Kantara was very explicitly a single event being described. When RISC, OIDC sessions, and eventually SCIM came to the conersation, the group decided to try out a way to express multiple aspects of a single event in a single token. While I still agree with this principle, I can see now that it's too much of a temptation to express either multiple events or bend around the semantics in ways that could cause a lot of confusion. I now think that we should collapse the syntax as Annabelle has suggested and go even further to specify what can go where. To wit, SET payload profiles should only ever touch the things inside the event object. So I'm proposing that we do something like this:
> 
> 
> {
> sub: <-- string representing the subject of the SET from the  view of the issuer (if known), no format assumed
> iat: <-- timestamp of when the SET Was created, not to be confused with the event time
> aud: <-- array or string repreesnting the recipients of this SET, from the view of the issuer of the sET
> event: { <-- object for the event itself, SET profiles do all of their definitions in here
>    toe: <-- timestamp of the event, if known; if not present, event time is unknown
>    iss: <-- issuer namespace for the subject of this event, as known by the recipient
>    sub: <-- subject of the event, as known by the recipient, namespaced by event.iss
>    event_type: <-- URI representing this event's type, must be understood by recipient (who can do a string match), can define other additional fields and their semantics
> }
> }
> 
>  <any event attributes that are common to the whole set, like txn, toe, sub, etc>
>  events: [  <-- array of event objects with the semantics of the regular event object, taken all at once; can re-use any of the root event elements defined in SET but must not repeat any in the root event's common attributes
>   ]
> }
> 
> Event groups create some interop issues, as you need to have clients that can handle events in a group as well as on their own. But with the way people were describing event groups today, I think that's actually a good thing -- it would force recognition of the associated nature of all the components. If you get an event group, you need to understand everything in the group. No primary/secondary, no pritical fields -- all or nothing.
> 
> Yes this is a change from current syntax and semantics, but to me it feels like a return to the consent receipt part of the roots.
> 
> -- Justin
> 
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=

---

From: Justin Richer <[email-masked]>
Date: Tue, 14 Nov 2017 11:42:16 +0800

Extensions to event types just extend the event object itself. So each 
event type controls the namespace within its event object and can allow 
additional bits in it. So let's say you've got:

event: {
  event_type: "foo:bar",
  foo: thing,
  bar: other-thing
  ...
}

And you want to extend "foo:bar" with the "foo:bar:baz" extension you could 
easily do something like:

event: {
  event_type: "foo:bar",
  foo: thing,
   bar: other-thing,
   baz: extension-thing
}

Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You 
could alternatively have an "extensions" object, but that seems like 
overkill. JSON in practice is schema-by-fiat: you look for things you know 
and care about and ignore everything else. So extensions can just stack 
inside the event object, and multiple extensions to the same event type 
will already need to know to stay out of each others' way.

 -- Justin

On November 14, 2017 10:35:51 AM Phil Hunt <[email-masked]> wrote:

>>    event_type: <-- URI representing this event's type, must be understood by 
>>    recipient (who can do a string match), can define other additional fields 
>>    and their semantics
>> }
>> }
>>

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 14 Nov 2017 11:48:31 +0800

I worry this causes potential namespace conflicts. 

I see complexity if each profile defines the method differently. Which undermines the value for the new proposal over the existing one. 

I would like to see an extension mechanism that is standard for set as part of the new proposal.  

Phil

> On Nov 14, 2017, at 11:42 AM, Justin Richer <[email-masked]> wrote:
> 
> Extensions to event types just extend the event object itself. So each event type controls the namespace within its event object and can allow additional bits in it. So let's say you've got:
> 
> event: {
>   event_type: "foo:bar",
>   foo: thing,
>   bar: other-thing
>   ...
> }
> 
> And you want to extend "foo:bar" with the "foo:bar:baz" extension you could easily do something like:
> 
> event: {
>   event_type: "foo:bar",
>   foo: thing,
>    bar: other-thing,
>    baz: extension-thing
> }
> 
> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever. You could alternatively have an "extensions" object, but that seems like overkill. JSON in practice is schema-by-fiat: you look for things you know and care about and ignore everything else. So extensions can just stack inside the event object, and multiple extensions to the same event type will already need to know to stay out of each others' way.
> 
> -- Justin
>> www.independentid.com
>> [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Tue, 14 Nov 2017 11:49:01 +0800

Justin: you have "sub" above the event, and within the event. I think there
are different values, but it is not clear.

On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer <[email-masked]> wrote:

>> Yes this is a change from current syntax and semantics, but to me it
>> feels like a return to the consent receipt part of the roots.
>>
>> -- Justin
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
>> ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=
>> RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=
>> na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-
>> dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=
>>
>>
>>
> https://www.ietf.org/mailman/listinfo/id-event
>
>

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

---

From: "Phil Hunt (IDM)" <[email-masked]>
Date: Tue, 14 Nov 2017 13:10:46 +0800

I withdraw my concern about extensions. 

Extensions can be added to grouping event type just like we did for events. That means any one can extend any event, even risc. Same outcome just an extra level of json for those of us who need it. 

Phil

> On Nov 14, 2017, at 11:48 AM, Phil Hunt (IDM) <[email-masked]> wrote:
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=xKhV2MrBhCnkvNpmfi1YxQW93GgUhANRCR8Cv0CbVtk&s=o2UMy3X8NKTXg2j84FbImFb6F7V2QrPxTkiVslrpUXE&e=

---

From: Justin Richer <[email-masked]>
Date: Tue, 14 Nov 2017 13:36:19 +0800

It ultimately is up to the extensions of a given event type to stay out of 
each other's way. I think the best thing for us would be to provide 
guidance. I don't think it's going to be a problem in practice as it's 
unlikely that two extensions to the same event type will be mutually 
unaware of each other.

On November 14, 2017 11:48:48 AM "Phil Hunt (IDM)" <[email-masked]> 
wrote:

> I see complexity if each profile defines the method differently. Which 
> undermines the value for the new proposal over the existing one.
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 14 Nov 2017 13:38:37 +0800

Yes, they're intended to be potentially different values but could be the 
same in some circumstances. Syntactically, one is "sub" and the other is 
"event.sub".  I'd be perfectly happy renaming the "event.sub" claim to 
"event.event_sub" or something, and I think the "risc_subject" with an 
object type is also perfectly reasonable as it's providing data beyond what 
the regular "event.sub" would do (as a string). Semantically, "sub" is from 
the perspective of the issuer of the SET and "event.sub" is the perspective 
of the receiver of the SET.

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Tue, 14 Nov 2017 13:43:48 +0800

Yes, if you want your extensions to have their own full object structure 
and have it be completely separate, you can use the group syntax. I think 
you can also, with this syntax, have a simpler extension mechanism that 
says "just add the 'baz' field into the exsting event object and it means 
'qux'".

 -- Justin

On November 14, 2017 1:11:04 PM "Phil Hunt (IDM)" <[email-masked]> wrote:

> Extensions can be added to grouping event type just like we did for events. 
> That means any one can extend any event, even risc. Same outcome just an 
> extra level of json for those of us who need it.
>
> Phil
>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 14 Nov 2017 13:46:36 +0800

Hey Justin, I'm having a hard time understanding the difference between
"sub" and "event.sub". Do you have an example that highlight the semantic
difference?

On Tue, Nov 14, 2017 at 1:38 PM, Justin Richer <[email-masked]> wrote:

>> Justin: you have "sub" above the event, and within the event. I think
>> there are different values, but it is not clear.
>>
>>
>>>> I wanted to take a few moments to get down on virtual-paper some
>>>> thoughts about the syntax and semantics of a SET from today's meeting.
>>>> Originally, the event snytax that we brought to the table from the Consent
>>>> Receipts working group in Kantara was very explicitly a single event being
>>>>    event_type: <-- URI representing this event's type, must be
>>>> understood by recipient (who can do a string match), can define other
>>>> additional fields and their semantics
>>>> }
>>>> }
>>>>
>>>>  events: [  <-- array of event objects with the semantics of the
>>>> regular event object, taken all at once; can re-use any of the root event
>>>> elements defined in SET but must not repeat any in the root event's common
>>>> attributes
>>>>   ]
>>>> }
>>>>
>>>> Event groups create some interop issues, as you need to have clients
>>>> that can handle events in a group as well as on their own. But with the way
>>>> 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=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-
>>>> kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=
>>>>
>>>>
>>>>
>> Subscribe to the HARDTWARE <http://hardtware.com/> mail list to learn
>> about projects I am working on!
>>
>

---

From: Justin Richer <[email-masked]>
Date: Tue, 14 Nov 2017 16:11:29 +0800

Sure, here's a somewhat concrete strawman. Let's say you've got an event 
issued by the RP in an identity system, sending information to another 
party (either the IdP or someone else). The "subject" from the OIDC 
perspective is what you'd find in an ID Token, say "abcd-1234". This only 
makes sense in the contex of the IdP's issuer, "https://id.example.com/", 
so it doesn't make sense to send the subject on its own without the issuer. 
However, the issuer of the SET itself is going to be the RP, 
"rp-client-id-1234" in the OIDC world or even "https://rp.example.net/" in 
a wider ecosystem.

So in this example, we want to talk about a user "abcd-1234" from 
"https://id.example.com/", but it's "rp-client-id-1234" that's talking 
about that user. Which gives us:

{
  "iss": "rp-client-1234",
  "event": {
    "iss": "https://id.example.com/",
    "sub": "abcd-1234"
  }
}

So why would you use "sub" at the root? Only if the issuer of the SET has 
their own, independent way to look at the user. In our case, let's say the 
RP has a local username identifier of "user-9876", you could have:

{
  "iss": "rp-client-1234",
  "sub": "user-9876",
  "event": {
    "iss": "https://id.example.com/",
    "sub": "abcd-1234"
  }
}

I think that the use of "sub" at the root should be less common than the 
use of "event.sub", in th use cases that people have brought up here. I'm 
against using "sub" as a shortcut for "event.sub", as has been suggested.

 -- Justin

---

From: Dick Hardt <[email-masked]>
Date: Tue, 14 Nov 2017 16:19:55 +0800

Thanks Justin.

What value would there be to the IdP to have the RP's identifier? Is there
a reason the IdP needs it?

I worry about the privacy implications of sharing the additional identifier
that the RP has that the IdP does not have.

On Tue, Nov 14, 2017 at 4:11 PM, Justin Richer <[email-masked]> wrote:

> "rp-client-id-1234" in the OIDC world or even "https://rp.example.net/"
> in a wider ecosystem.
>
> So in this example, we want to talk about a user "abcd-1234" from "
> https://id.example.com/", but it's "rp-client-id-1234" that's talking
>>> Yes, they're intended to be potentially different values but could be
>>> the same in some circumstances. Syntactically, one is "sub" and the other
>>> is "event.sub".  I'd be perfectly happy renaming the "event.sub" claim to
>>>>> Or you could make the lvalue "baz" to be "foo:bar:baz" or whatever.
>>>>> You could alternatively have an "extensions" object, but that seems like
>>>>>> lZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqP
>>>>>> kAI1aLcLN4KZNA&m=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg
>>>>>> &s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=
>>>>>>
>>>>>>
>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Tue, 14 Nov 2017 23:53:00 +0800

For the strawman, no, the IdP wouldn't need it. An audit system that knows 
about the RP's storage/lookup might need it. That's why, if we include it 
in the spec, we'd want some language making it clear that it's only within 
the view of the party generating the SET and that if it's for consumption 
externally the user should be identified by a field in the event, or event.sub.

 -- Justin

---

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Wed, 15 Nov 2017 02:27:37 +0000

I think those are semantics that could be declared by a Profiling Specification.

--
Annabelle Richard Backman
Amazon – Identity Services

From: Id-event <[email-masked]> on behalf of Justin Richer <[email-masked]>
Date: Tuesday, November 14, 2017 at 11:53 PM
To: Dick Hardt <[email-masked]>
Cc: SecEvent <[email-masked]>, Phil Hunt <[email-masked]>
Subject: Re: [Id-event] Thoughts on Syntax from today's meeting

For the strawman, no, the IdP wouldn't need it. An audit system that knows about the RP's storage/lookup might need it. That's why, if we include it in the spec, we'd want some language making it clear that it's only within the view of the party generating the SET and that if it's for consumption externally the user should be identified by a field in the event, or event.sub.

-- Justin

What value would there be to the IdP to have the RP's identifier? Is there a reason the IdP needs it?

I worry about the privacy implications of sharing the additional identifier that the RP has that the IdP does not have.

On Tue, Nov 14, 2017 at 4:11 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

Sure, here's a somewhat concrete strawman. Let's say you've got an event issued by the RP in an identity system, sending information to another party (either the IdP or someone else). The "subject" from the OIDC perspective is what you'd find in an ID Token, say "abcd-1234". This only makes sense in the contex of the IdP's issuer, "https://id.example.com/", so it doesn't make sense to send the subject on its own without the issuer. However, the issuer of the SET itself is going to be the RP, "rp-client-id-1234" in the OIDC world or even "https://rp.example.net/" in a wider ecosystem.

So in this example, we want to talk about a user "abcd-1234" from "https://id.example.com/", but it's "rp-client-id-1234" that's talking about that user. Which gives us:

{
  "iss": "rp-client-1234",
  "event": {

So why would you use "sub" at the root? Only if the issuer of the SET has their own, independent way to look at the user. In our case, let's say the RP has a local username identifier of "user-9876", you could have:

{
  "iss": "rp-client-1234",
  "sub": "user-9876",
  "event": {

I think that the use of "sub" at the root should be less common than the use of "event.sub", in th use cases that people have brought up here. I'm against using "sub" as a shortcut for "event.sub", as has been suggested.

-- Justin

On November 14, 2017 1:47:05 PM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Hey Justin, I'm having a hard time understanding the difference between "sub" and "event.sub". Do you have an example that highlight the semantic difference?

On Tue, Nov 14, 2017 at 1:38 PM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

Yes, they're intended to be potentially different values but could be the same in some circumstances. Syntactically, one is "sub" and the other is "event.sub".  I'd be perfectly happy renaming the "event.sub" claim to "event.event_sub" or something, and I think the "risc_subject" with an object type is also perfectly reasonable as it's providing data beyond what the regular "event.sub" would do (as a string). Semantically, "sub" is from the perspective of the issuer of the SET and "event.sub" is the perspective of the receiver of the SET.

-- Justin

On November 14, 2017 11:49:27 AM Dick Hardt <[email-masked]<mailto:[email-masked]>> wrote:
Justin: you have "sub" above the event, and within the event. I think there are different values, but it is not clear.

On Tue, Nov 14, 2017 at 11:42 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

event: {
  event_type: "foo:bar",
  foo: thing,
  bar: other-thing
  ...
}

event: {
  event_type: "foo:bar",
  foo: thing,
   bar: other-thing,
   baz: extension-thing
}

-- Justin

On November 14, 2017 10:35:51 AM Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
How do you propose to handle extensions of event uris?

Phil

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

On Nov 14, 2017, at 2:21 AM, Justin Richer <[email-masked]<mailto:[email-masked]>> wrote:

{

event: {

-- Justin

_______________________________________________
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=y2OPleUr8EEEMvEMVjHNWNm-dFJbnVcSztxsB-kpYFg&s=FZu1FlqDXhYE2GzdLPFsbjYGIS8UW9CdLs_wOOdcD-g&e=

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

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

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

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