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

[Phil Hunt <[e-mail]>]

Just to refresh everyone...

As editor, my feeling is we have no *clean* or *simple* solution because we have to use “iss” to mean the issuer of the SET in order to comply with JWT and because OIDC conflates assertion issuer with subject issuer, it makes it difficult to uniquely identify a “sub” value because some events want to use “iss” for 2 purposes (to identify the event issuer vs. the subject issuer).

None of the solutions presented are actually easy to explain. So far, I’ve sided with Mike and William because they feel it is close enough and it was editorially lazy (say nothing). I am worried that this is actually complex for developers who do not know the history of how JWTs emerged.

Let’s look at the examples we already have. Notice that in the current draft, there are 3 separate ways of expressing the subject of an event….

Scenario 1, the event issuer and subject issuer are the same:

   {
      "iss": "https://server.example.com",
      "sub": "248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
   }

Scenario 2, a relying party is issuing an event, event iss and sub iss are different and thus there are repeat iss values:

   {
     "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"
         ]
       }
     }
   }

Scenario  3:  sub is universally unique:

   {
     "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
     "iat": 1458496025,
     "iss": "https://scim.example.com",
     "aud": [
       "https://jhub.example.com/Feeds/98d52461fa5bbc879593b7754",
       "https://jhub.example.com/Feeds/5d7604516b1d08641d7676ee7"
     ],
     "sub": "https://scim.example.com/Users/44f6142df96bd6ab61e7521d9",
     "events": {
       "urn:ietf:params:scim:event:passwordReset":
         { "id":"44f6142df96bd6ab61e7521d9"},
       "https://example.com/scim/event/passwordResetExt":
         { "resetAttempts":5}
     }
   }

I believe the current argument is that profiling specs explains how their events are to be parsed. This means for multi-event parsers, subject is inconsistent and potentially not mappable.  The BackChannel Logout event is currently structured for only the OP to issue. However Oracle wants that to be bi-directional so that web sites can notify the IDP/OP that the user has logged out of a specific web site.  If that happens, BackChannel logout will have methods 1 and 2 required.

Would it be possible for events to require that “sub” be globally unique — e.g. expressed as a url.  For example, in order for backchannel to be issued by an OP or an RP, it would be expressed with sub as a URL ("sub": “https://server.example.com/248289761001”,):
   {
      "iss": "https://www.exampleapp.com",
      "sub": “https://server.example.com/248289761001",
      "aud": "s6BhdRkqt3",
      "iat": 1471566154,
      "jti": "bWJq",
      "sid": "08a5019c-17e1-4977-8f42-65a12843ea02",
      "events": {
        "http://schemas.openid.net/event/backchannel-logout": {}
      }
 
At least this way iss is never duplicated and sub is always the addressable subject of the event regardless of the type of event.  That would enable all 3 cases to be expressed one way for all specs.  That seems simple to me (at least from how I would define this in the spec).  

I had thought Justin was advocating a 4th option which is to always embed “sub” and “iss” in the event payload.  So you would end up with something like:
   {
     "jti": "fb4e75b5411e4e19b6c0fe87950f7749",
     "iat": 1458496025,
     "iss": "https://my.examplemed.com",
     "aud": [
       "https://rp.example.com"
     ],
     "events": {
       "https://openid.net/heart/specs/consent.html":{
         "sub": "248289761001",
         "iss":"https://my.examplemed.com",
         "consentUri":[
           "https://terms.examplemed.com/labdisclosure.html#Agree"
         ]
       }
     }
   }

Note that in the above example, “iss” would always be present even if “iss” is the *same*.  The rule would be that the iss and sub are in the payload and that addresses the subject of the event. The envelope level is always reserved for event validation and addressing only.  While some would argue this is ugly, I can see some merits as it is at least consistent.


Phil

Oracle Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com <http://www.independentid.com/>[e-mail] <mailto:[e-mail]>







> On Mar 7, 2017, at 7:26 AM, Justin Richer <[e-mail]> wrote:
> 
> +1
> 
> 
> On 3/6/2017 7:55 PM, Benjamin Kaduk wrote:
>> On 03/06/2017 06:39 PM, Mike Jones 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.
>>> 
>> 
>> That seems a dangerous road to tread, as it requires care in defining "information" -- duplicating the same data strings at different levels of the hierarchy of a JSON object may very well not be duplicating information, due to the extra context provided by the hierarchy.  In my mind, it's not a clear case that you should never send the same name/value multiple times in different parts of an object, as sometimes it is good to keep the semantic separation clear.
>> 
>> -Ben
> 
>