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

[Mike Jones <[e-mail]>]

Leave this as-is.  Adding additional claims that have the same meanings as existing claims but that use different syntax is needless complexity.

Like JWTs, we should keep SETs as simple as possible.  Also like JWTs, particular events will use the claims that they need.  This is as it should be.

                                                                -- Mike

From: Id-event [mailto:[e-mail]] On Behalf Of Phil Hunt
Sent: Wednesday, March 1, 2017 10:28 AM
To: ID Events Mailing List <[e-mail]>
Subject: [Id-event] Thread: Clarifying use of sub and iss in SET tokens

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]>