Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

[Justin Richer <[e-mail]>]

Yes, exactly. I believe the event payload should have clearly defined 
semantics within the event object itself. Claims within the object are 
defined and controlled by the event, and things outside the object are 
applicable to the SET itself. We already have several use cases listed 
where the issuer is different for the token and the event, and the 
subject and audience may be different as well. It's clear to me that 
this indicates that we should have clearly defined separation between 
the envelope (the SET) and the payload (the event).

I believe that duplication of information *lessens* the chance of error 
cases as there's now only one way to interpret each piece of data. If I 
get a token and I read "payload.iss" I know that it's the issuer of the 
SET. If I then read "payload.heart-resource-server-access-uri.iss" I 
know it's the issuer of the HEART audit event (to throw a strawman of 
one of many examples out there).

Yes, an event type could define its payload to never include "iss" 
inside of it and say "the issuer of the SET MUST be the same as the 
issuer of the event", if you really feel like optimizing things in your 
particular use case. But I do need to ask why you'd do that to yourself: 
If both issuers (or subjects, or audiences) are the same, then what harm 
is there in repeating the information other than to make the event body 
potentially larger? These aren't ID tokens being chucked around in 
browsers, so if that's the motivation I ask if we're not pre-optimizing 
a problem that we don't have.

In all cases I believe the SET definition should be very clear that any 
claims at the root apply to the SET itself and don't automatically flow 
down to the events inside the data objects within. The claims inside the 
event objects should be strictly more specifically applied to the events 
themselves.

  -- Justin


On 3/4/2017 7:55 PM, Phil Hunt (IDM) wrote:
> That seems unclear.
>
> Do you mean put subj ans issuer inside the payload regardless of 
> whether the issuer of the event is the same or different from the 
> subject?  That way it is always the same though it may be duplicative?
>
> Phil
>
> On Mar 4, 2017, at 2:56 PM, Justin Richer <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> 3:
>>
>> Put "iss" and "sub" inside the event when they apply to the event, 
>> even if they're the same as the "iss" and "sub" of the event token 
>> itself.
>>
>>  -- Justin
>>
>> On 3/1/2017 1:27 PM, Phil Hunt wrote:
>>> In the comments on idtoken-07, Yaron raised concerns around the 
>>> confusion of “iss” of the subject of the event vs. issuer of the 
>>> event.  The current text says that if there is a need to distinguish 
>>> between “iss” of the “sub” vs. “iss” of the event, then the event 
>>> should place the “iss” of the subject in the event payload area.
>>>
>>> I agree this does seem awkward.
>>>
>>> I have been thinking a related concern, that a SET could be confused 
>>> as an access token if it has a “sub” value.  If we stop using “sub” 
>>> then we’re potentially causing web access management systems to 
>>> reject SETs as invalid access tokens — this is theoretically a GOOD 
>>> THING.
>>>
>>> PLEASE INDICATE 1 or 2, or provide additional discussion.
>>>
>>> Two options:
>>>
>>> 1. Leave as is.
>>>
>>> 2.  Create a new attribute object, “esub” (event subject) which is a 
>>> JSON object that contains the attributes needed to identify the 
>>> subject.  For example:
>>>
>>> We currently have:
>>>>     {
>>>>       "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
>>>>
>>>>       "sub": "248289761001",
>>>>       "iat": 1458496025,
>>>>       "iss": "https://my.examplemed.com <https://my.examplemed.com/>",
>>>>       "aud": [
>>>>         "https://rp.example.com"
>>>>       ],
>>>>       "events": {
>>>>         "https://openid.net/heart/specs/consent.html":{
>>>>           "iss":"https://connect.example.com",
>>>>           "consentUri":[
>>>>             "https://terms.examplemed.com/labdisclosure.html#Agree"
>>>>           ]
>>>>         }
>>>>       }
>>>>     }
>>>
>>> Could be represented as:
>>>     {
>>>       "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
>>>
>>>       “esub": {
>>>         “sub”:"248289761001”,
>>>         "iss":"https://connect.example.com”
>>>       }
>>>       "iat": 1458496025,
>>>       "iss": "https://my.examplemed.com <https://my.examplemed.com/>",
>>>       "aud": [
>>>         "https://rp.example.com"
>>>       ],
>>>       "events": {
>>>         "https://openid.net/heart/specs/consent.html":{
>>>           "consentUri":[
>>>             "https://terms.examplemed.com/labdisclosure.html#Agree"
>>>           ]
>>>         }
>>>       }
>>>     }
>>>
>>> Comments:
>>> * “sub” remains untouched in the sense that it retains the meaning 
>>> used in traditional access tokens.
>>> * “esub” contains the full information to address the subject.  No 
>>> need to look around for a second “iss” (which may or may not be there)
>>>
>>> To do this would require defining “esub” and sub-attributes like, 
>>> “iss”, “sub” (which follow current defs), and probably “uri” for 
>>> those entities that are referenceable as a URI.  Examples of URI 
>>> subjects:
>>> *  in implicit federation (from RISC): 
>>> “uri”:”mailto:[e-mail]”
>>> *  in SCIM where resources have URIs: 
>>>  “uri”:”https://scim.example.com/Users/44f6142df96bd6ab61e7521d9"
>>>
>>> One catch. Profiling specs would not be able to define new ways of 
>>> addressing subjects with esub.
>>>
>>> Phil
>>>
>>> Oracle Corporation, Identity Cloud Services & Identity Standards
>>> @independentid
>>> www.independentid.com <http://www.independentid.com>
>>> [e-mail] <mailto:[e-mail]>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Id-event mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/id-event
>>