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

Sarah Squire sarah at engageidentity.com
Thu Aug 11 18:10:01 UTC 2016


Are we including use cases where the RP is the event issuer?

On Aug 11, 2016 11:02 AM, "Mike Jones" <Michael.Jones at microsoft.com> wrote:

> You’re aware that forcing “sub” to be a URI is a breaking change for most
> implementations, right?  This is hardly a way to encourage adoption!
>
>
>
> The thing you wrote below that makes me think that you’re thinking about
> the purpose of the ID Events spec differently than me is this: “so that
> all event specs can use it”.  The purpose of the logout event **isn’t**
> for all event specs to use it.  It’s for the logout use case to use it.
> There’s no expectation that events intended for one use case will even be
> comprehensible in other use cases because they won’t understand the
> contents of the event.  We shouldn’t drive any of the design by trying to
> achieve that unachievable goal, since events will **always** contain
> information that’s specific to their use case.
>
>
>
> You’re making complexity arguments, whereas you’re also proposing more
> complex rules than I am (at least as I see it).  Trying to restrict the use
> of “sub” (or any other claims) is unneeded complexity.
>
>
>
> I understand that you see things differently.  I hope you’ll nonetheless
> think about my argument that having fewer rules about claims usage in
> events will make them simpler.  I passionately care about keeping this
> simple, which is why I’m investing my time in this discussion.  If it’s
> simple, it will likely get widely used.
>
>
>
> I’m going to sign out of the discussion for now because my wife is about
> to get out of surgery.  I hope you have a good day.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Phil Hunt [mailto:phil.hunt at oracle.com]
> *Sent:* Thursday, August 11, 2016 12:49 PM
> *To:* Mike Jones <Michael.Jones at microsoft.com>
> *Cc:* John Bradley <ve7jtb at ve7jtb.com>; openid-specs-ab at lists.openid.net
> Ab <openid-specs-ab at lists.openid.net>; id-event at ietf.org; Marius
> Scurtescu <mscurtescu at google.com>
> *Subject:* Re: [Id-event] Summarizing recent discussions on ID-Event
> token draft
>
>
>
> 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",
>
>   "aud": "s6BhdRkqt3",
>
>   "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>
>   "sub": “https://token.example.com/248289761001",
>
>   "iat": 1458668180,
>
>   "exp": 1458668580,
>
>   "events": [
>
>     "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
>
> 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>
> 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>
> 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]
> *Sent:* Thursday, August 11, 2016 9:40 AM
> *To:* Mike Jones <Michael.Jones at microsoft.com>
> *Cc:* Marius Scurtescu <mscurtescu at google.com>; 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>
> 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]
> *Sent:* Tuesday, August 9, 2016 7:15 PM
> *To:* Phil Hunt <phil.hunt at oracle.com>
> *Cc:* Mike Jones <Michael.Jones at microsoft.com>; 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> 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
>
> phil.hunt at oracle.com
>
>
>
>
>
>
>
>
>
> On Aug 9, 2016, at 12:12 PM, Mike Jones <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”
> 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]
> *Sent:* Tuesday, August 9, 2016 12:07 PM
> *To:* Mike Jones <Michael.Jones at microsoft.com>
> *Cc:* 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
>
> phil.hunt at oracle.com
>
>
>
>
>
>
>
>
>
> On Aug 9, 2016, at 11:54 AM, Mike Jones <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] *On Behalf Of *Phil
> Hunt
> *Sent:* Tuesday, August 9, 2016 10:19 AM
> *To:* 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
>
>
>
> 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",
>
>   "aud": "s6BhdRkqt3",
>
>   "jti": "3d0c3cf797584bd193bd0fb1bd4e7d30",
>
>   "iat": 1458668180,
>
>   "exp": 1458668580,
>
>   "events": [
>
>     "https://specs.openid.net/logout"
>
>   ],
>
>   "https://specs.openid.net/logout": {
>
>     <- This level is defined entirely by the event URI->
>
>     "iss": "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
>
> phil.hunt at oracle.com
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> 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
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> 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
>
>
>
> _______________________________________________
> Id-event mailing list
> Id-event at ietf.org
> 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/564a89cb/attachment-0001.html>


More information about the Openid-specs-ab mailing list