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

[Mike Jones <[e-mail]>]

Justin, I suspect you didn’t see my earlier reply to Phil’s note that you also replied to, so I’m repeating it here and sending it to you directly.  (It wouldn’t be the first time that DMARC policies caused some of my contributions to be not received by some participants. :-( )

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: Id-event [mailto:[e-mail]] On Behalf Of Justin Richer
Sent: Sunday, March 5, 2017 5:13 AM
To: Phil Hunt (IDM) <[e-mail]>
Cc: ID Events Mailing List <[e-mail]>
Subject: Re: [Id-event] Thread: Clarifying use of sub and iss in SET tokens


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]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/id-event