[Openid-specs-ab] [Id-event] Summarizing recent discussions on ID-Event token draft

Phil Hunt phil.hunt at oracle.com
Thu Aug 11 16:49:20 UTC 2016


Mike, 

Speaking as editor the format you propose ONLY works if “sub” becomes a URI so that all event specs can use it.  Otherwise, OIDC becomes a special case which really kills the point of this work. It also makes the specification much much more complex. Maybe it is just me, but a complex spec generally implies complex implementation too.

If you want sub at the top level, that would mean that the OIDC spec format would have to look like:
{
  "iss": "https://event.example.com <https://event.example.com/>",
  "aud": "s6BhdRkqt3",
  "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
  "sub": “https://token.example.com/248289761001",
  "iat": 1458668180,
  "exp": 1458668580,
  "events": [
    "https://specs.openid.net/logout <https://specs.openid.net/logout>"
  ],
  "sid": "08a5019c-17e1-4977-8f42-65a12843ea02"
}

Given that events are signed (or should be), I will object strongly within the OIDF that the event issuer and the token issuer MUST be the same or that OIDF adopt a different format. Yes having iss be the same is a nice security convenience, but it imposes the architecture restriction that it be the same server.  At scale, delivery of events may become a problem for large scale providers if they are also delivering tokens to relying parties. The restriction isn’t really justified given the crypto alternative — which was the whole point of using JWT in the first place.

Per Justin’s comment, it seems elegant/trivial that a logout event simply has logout at the top level and an ID Token attached (though it might convey a lot of unneeded claims).  IMO, the OIDC logout spec should only convey the ID Token JTI.  It is going to be rare that you log out all devices for a user.  To most users, it means clear SSO within this browser only!  One can argue that clearing all devices/sessions is a different event entirely. It is an account reset or lock-out action.

Phil

@independentid
www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>





> On Aug 11, 2016, at 9:32 AM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
> See my previous message, John, which was a reply to Phil’s message that you also replied to, that contained a logout claims example.  I’m not proposing to special-case the Connect Logout message in any way.  The “iss” is the event issuer.  The other claims in the message are those defined by the event to be included, just like those for any other event.  Yes, the logout message doesn’t include a second issuer, a second subject, an ID Token as a claim, or anything else complicated like that, because those things aren’t needed for the logout use case.
>  
> As I’d written previously, the ID Events spec should define the “events” claim, how to use an event name as a claim (when needed), and say that the event JWT must be signed by the issuer, and stop there.  Trying to micro-manage claims usage within an event will only result in the ID Events spec being harder to use.  If we’d tried to similarly micro-manage JWT claims usage, JWT would likely not have been the success that it is.
>  
>                                                        -- Mike
>   <>
> From: John Bradley [mailto:ve7jtb at ve7jtb.com] 
> Sent: Thursday, August 11, 2016 12:22 PM
> To: Phil Hunt (IDM) <phil.hunt at oracle.com>
> Cc: Mike Jones <Michael.Jones at microsoft.com>; id-event at ietf.org; Marius Scurtescu <mscurtescu at google.com>; openid-specs-ab at lists.openid.net Ab <openid-specs-ab at lists.openid.net>
> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft
>  
> Not surprisingly a multipurpose message format will not be as optimized as a single purpose one.
>  
> Connect itself doesn’t really have a conflict around issuer the same entity sending the logout message is always the one that created the id_token that it refers to.
>  
> Using the same format as id_token with the same semantics to identify the thing to be terminated makes sense from a purely openID Connect point of view.
>  
> Oter messages that have different notions of subject and are issued by different parties than the one that controls the subject cause issues when you try and fit them into the same format as an ID_Token, I grant you that.
>  
> It was mentioned that we need to differentiate between these events and id_tokens.  Mostly we need to do that in cases where the token might be presented in the front channel.
>  
> To do that se do have mandatory claims for nonce and c_hash or at_hash as well as the addition of events parameter to reduce confusion.   Now I admit that some people may still get that wrong,  and the removal of sub from the top level would remove any concern.  However Mike has a point that adoption may be hurt if we change the semantics too much.
>  
> I don’t see backchannel single logout being used by many social login RP, it is a lot of work to maintain server side state.   It is mostly an enterprise and large site sort of feature.
> That may or may not impact on if it is better to be simple and aligned with connect’s id token or more general purpose to fit with other enterprise to SaaS features like SCIM events.
>  
> I think the two directions lead to different formats.   
>  
> The compromise of special casing Connect SLO and bodging the formats together is probably the worst option.
>  
> John B.
>  
>  
> On Aug 11, 2016, at 11:59 AM, Phil Hunt (IDM) <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>> wrote:
>  
> How do you resolve conflicts on iss then?  The top level has to be the issuer of the event as the issuer signs. 
>  
> If one spec can use it all must be able to. I believe you previously objected to that saying sub must be as how id tokens define them. But that isnt unique and requires iss. Now we would have sub at the top with an event issuer at the top and a sub issuer in the extension. That seems incredibly complex not to mention awkward. 
>  
> If we make sub a uri for all then it can work ass iss from id token would not be needed. But i can see many objecting to the change in format. 
>  
> Why not have a logout be an event with an id token attached for example?
> 
> Phil
> 
> On Aug 11, 2016, at 8:03 AM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
> 
> The simple rule is that if the particular event calls for the “sub” claim to be at the top level, then it is.  This is no different from any other claim that an event might place at the top level.
>  
> The complexity arises if “sub” is unnecessarily special-cased.  We shouldn’t do that, because it limits the applicability of the specification.
>  
>                                                        -- Mike
>  
> From: Phil Hunt (IDM) [mailto:phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>] 
> Sent: Thursday, August 11, 2016 9:40 AM
> To: Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>>
> Cc: Marius Scurtescu <mscurtescu at google.com <mailto:mscurtescu at google.com>>; id-event at ietf.org <mailto:id-event at ietf.org>
> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft
>  
> I think using sub at the top level leads to complexity. Eg Can you provide a rule for when top level is used or not by an individual spec?  IMO. Top level should always be used the same way by all implementers. 
>  
> Based on the calls at risc/connect, we discussed that it would be best to move all event specifics to the event object area. This way different events can have different event addressing (eg sub/iss, uri, jit/iss). When iss is needed to uniquely qualify a sub, it can be provided without conflicting with the issuer of the event. Similarly jti and iss can be used for a revoked token without conflicting with the event jti. 
>  
> I plan to post a new draft shortly that will give some examples based on feedback from the openid risc/connect discussions.
>  
> We can always change again. 
> 
> Phil
> 
> On Aug 11, 2016, at 4:54 AM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
> 
> No, I’m not saying that “sub” cannot appear at the top level.  I’m saying that “sub” will only occur at the top level if the particular event defines that “sub” is used in that way for that event.
>  
> There are probably use cases for multiple events per message but I doubt there are use cases for multiple *unrelated* events per message.  By definition, related events that use top-level claims would need to use them in a compatible way.  I don’t see that as being a problem.
>  
> That being said, the predominant use case is likely to be a single event per JWT.
>  
>                                                                      -- Mike
>  
> From: Marius Scurtescu [mailto:mscurtescu at google.com <mailto:mscurtescu at google.com>] 
> Sent: Tuesday, August 9, 2016 7:15 PM
> To: Phil Hunt <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>>
> Cc: Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>>; id-event at ietf.org <mailto:id-event at ietf.org>
> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft
>  
> Mike, are you suggesting that a sub claim can only show up at the event level and not at the top level:
>  
> In particular, the only thing that the spec should say about the “sub” claim is that “Like all other claims other than ‘events’ and ‘iss’, whether the ‘sub’ claim is to be included with an event is entirely event-specific.
>  
> A top level sub and multiple events are incompatible IMO.
>  
> Do we have a compelling reason to support multiple events per message?
>  
> 
> Marius
>  
> On Tue, Aug 9, 2016 at 12:39 PM, Phil Hunt <phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>> wrote:
> I was referring to this in your email
> "Define that an event name can be used as a top-level claim”
>  
>  
> Is this different from the event uri?
>  
> Phil
>  
> @independentid
> www.independentid.com <http://www.independentid.com/>
> phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>  
>  
>  
> 
>  
> On Aug 9, 2016, at 12:12 PM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>  
> I’m glad to hear that we agree on keeping it as simple and general-purpose as possible and that you agree with my write-up.  I think we then have a good path forward.
>  
> I’m not sure what you mean by “I’m not sure that we need a “name”. What is your intention there.”  The only place I used the word “name” was in my statement “Define that an event name can be used as a top-level claim”.  What I was trying to get at is was that if “http://specs.openid.net/logout <http://specs.openid.net/logout>” is used as an event name, that it can also be used as a claim name in the JWT containing information about the event.  (Maybe I’m not using the correct terminology, hence the unintended confusion J.)
>  
>                                                        Thanks again,
>                                                        -- Mike
>   <>
> From: Phil Hunt [mailto:phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>] 
> Sent: Tuesday, August 9, 2016 12:07 PM
> To: Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>>
> Cc: id-event at ietf.org <mailto:id-event at ietf.org>
> Subject: Re: [Id-event] Summarizing recent discussions on ID-Event token draft
>  
> I didn’t cover this as I didn’t want to confuse people with too many things.
>  
> But I think we agree on all of the below.
>  
> I’m not sure that we need a “name”. What is your intention there.
>  
> Phil
>  
> @independentid
> www.independentid.com <http://www.independentid.com/>
> phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>  
>  
>  
> 
>  
> On Aug 9, 2016, at 11:54 AM, Mike Jones <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>  
> Thanks for writing this, Phil.  Unfortunately, the summary below does not include my feedback, which at the essence, is to keep the ID Events data structure as simple and general-purpose as possible.  (I strongly believe that JWT is the success it is because we made JWT as simple and general-purpose as possible, and we should follow this successful example and do the same here.)
>  
> I believe that the ID Events spec needs to include these things, and these things only:
> ·       Define of the “events” claim
> ·       Define that an event name can be used as a top-level claim
> ·       Require that “iss” be included and that the JWT be signed by the issuer
> ·       Include a statement along the lines of “The claims to be included with any particular event are to be defined by the event”
>  
> And I’d stop there.
>  
> It should be entirely up to applications to say what claims are included with events they define and what their format and meanings are.  Then the ID Events spec will be as general-purpose as possible, with it being natural for it to be used in essentially all JSON Event contexts.
>  
> As soon as we start putting restrictions on the use of particular claims by events, we’re making the ID Events spec less general-purpose and less natural to use.  In particular, the only thing that the spec should say about the “sub” claim is that “Like all other claims other than ‘events’ and ‘iss’, whether the ‘sub’ claim is to be included with an event is entirely event-specific.  The claims to be included with any particular event are explicitly outside the scope of this specification.”
>  
>                                                        -- Mike
>  
> From: Id-event [mailto:id-event-bounces at ietf.org <mailto:id-event-bounces at ietf.org>] On Behalf Of Phil Hunt
> Sent: Tuesday, August 9, 2016 10:19 AM
> To: id-event at ietf.org <mailto:id-event at ietf.org>
> Subject: [Id-event] Summarizing recent discussions on ID-Event token draft
>  
> I thought I would update the list on some discussions that have been happening over in the OpenID Connect and RISC working groups conference calls.
>  
> These discussions have been about the core spec and the role of “top-level” attributes vs. event “extension” attributes. 
> See: https://tools.ietf.org/html/draft-hunt-idevent-token-01 <https://tools.ietf.org/html/draft-hunt-idevent-token-01>
>  
> In particular should “sub” be used in the top level to “point” to the subject (in the broader english sense) of the event, or should it be constrained to the SAML/ID Token definition which is the authenticated user.  
>  
> Taken in the narrower definition, it is important to observe that in an ID Token, “sub” and “iss” go together.  The issuer provides the context for the authenticated subject identifier. The problem with events, is that it might not be the AS (or OP) which is issuing the event.  
>  
> To summarize a fair amount of discussion, the feeling seems to be the following:
>  
> *  The Event Token top level attributes should be fairly limited and not include the sub attribute.  
> *  For events that are about a user, the relevant event specification may include a “sub” attribute within the event’s sub-object and not in the top-level. Further that sub-object can also include the issuer of the user.  
> * The top-level “iss” shall mean the issuer of the event where the state change occurred.
> *  “sub” should not be present in the top level structure.  Also, “events” must also be present.
>  
> Here would be a new example logout:
> {
>   <— top level is about the event itself ->
>   "iss": "https://server.example.com <https://server.example.com/>",
>   "aud": "s6BhdRkqt3",
>   "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>   "iat": 1458668180,
>   "exp": 1458668580,
>   "events": [
>     "https://specs.openid.net/logout <https://specs.openid.net/logout>"
>   ],
>   "https://specs.openid.net/logout <https://specs.openid.net/logout>": {
>     <- This level is defined entirely by the event URI->
>     "iss": "https://oidc.example.com <https://oidc.example.com/>",
>     “jti": "08a5019c-17e1-4977-8f42-65a12843ea02”,
>     "sub": "248289761001”,
>     “exp”: <ID token expiry>
>   }
> }
>  
> In the above example note that the “event” object can have its own iss and subject (sub or jti) that have meaning within the context of an OpenID OP provider.  The issuer of the event can be different (the top-level) and represents the entity that signs the event (if it is signed).
>  
> The top-level attributes identify an individual event and are used to validate the event (signing etc).  Where as the nested object contains all of the data about the event and is defined by the profiling specification (e.g. a possible OpenID Logout Event spec).  In this case, in OpenID, logging out usually translates into revoking an ID Token. Thus the “jti” for the ID token (08a5019c...843ea02) is included in the Logout object.
>  
> Side note.  Regarding “logout”, it might be useful to include the expiry of the ID Token in case the subscriber has not yet received an ID Token. This would let the subscriber know how long it needs to keep the revocation information for.  IOW…after the the ID Token is expired, the subscriber would no longer need to track the revocation state.
>  
> It is also good to observe that the “aud” at the top level describes the subscriber of the event.  This may also be different then the original audience of the ID Token.
>  
> So to conclude. By making top-level attributes strictly about the events own validation, and nested objects about the event, we avoid collisions in definitions such as the issuer of the event, vs. the original issuer of a security assertion.
>  
> I hope I’ve gotten everyone’s feedback correct here. Lets continue to discuss. I will revise the draft to follow the groups thinking here.
>  
> Phil
>  
> @independentid
> www.independentid.com <http://www.independentid.com/>
> phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
>  
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org <mailto:Id-event at ietf.org>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> 
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org <mailto:Id-event at ietf.org>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org <mailto:Id-event at ietf.org>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org <mailto:Id-event at ietf.org>
> https://www.ietf.org/mailman/listinfo/id-event <https://www.ietf.org/mailman/listinfo/id-event>
>  
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> https://www.ietf.org/mailman/listinfo/id-event

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160811/6832e10b/attachment-0001.html>


More information about the Openid-specs-ab mailing list