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

[William Denniss <[e-mail]>]

I think SET should not be opinionated on this, and not try and solve
everything.

Backchannel logout already has an acceptable solution for their case, and
are not asking for a "fix".  It looks like RISC may create it's own
solution to solve this issue, and may not want SET to do anything.

Let's keep SET generic, in the same way JWT itself is, and add some text in
the Security Considerations.

I fear that introducing normative text (like using "crit") to "fix" an
issue with the way some people are using JWT in unrelated specs seems to be
scope-creep.  We can then focus our energies on the primary mission of the
event definition.


On Mon, Mar 6, 2017 at 4:49 PM, Phil Hunt (IDM) <[e-mail]>
wrote:

> In my view it is only simple  if we keep iss and sub together. This
> creates the conflict when the SET issuer is not same as the subject issuer.
> For example when an RP issues an event about an IDP/OP's subject. This will
> happen a LOT.
>
> I do not believe the current text actually works in this regard. I would
> prefer not to punt this to profiling specs to clarify as this will create a
> lot of interop and inconsistent use issues.
>
> I think Justin has a point here.
>
> Phil
>
> On Mar 6, 2017, at 4:39 PM, Mike Jones <[e-mail]>
> wrote:
>
> 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]
> <[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]> 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",
>
>      "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",
>
>      "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]
> <[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
>
> [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Id-event mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/id-event
>
>
>
>
>
>
> _______________________________________________
> Id-event mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/id-event
>
>