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

[Justin Richer <[e-mail]>]

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