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

[Phil Hunt <[e-mail]>]

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 <https://openid.net/heart/specs/consent.html>":{
>          "iss":"https://connect.example.com",
>          "consentUri":[
>            "https://terms.examplemed.com/labdisclosure.html#Agree <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 <https://openid.net/heart/specs/consent.html>":{
         "consentUri":[
           "https://terms.examplemed.com/labdisclosure.html#Agree <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]>