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

[Mike Jones <[e-mail]>]

Agreed that this is unclear.  Duplicating information in a protocol *always* introduces an unnecessary error case – the need to define how to handle the situation in which two pieces of information that are required to be identical are different.  Information in a SET should occur at most once.

– Mike

From: Phil Hunt (IDM)<mailto:[e-mail]>
Sent: Saturday, March 4, 2017 4:56 PM
To: Justin Richer<mailto:[e-mail]>
Cc: ID Events Mailing List<mailto:[e-mail]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/id-event