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

Sarah Squire sarah at engageidentity.com
Thu Aug 11 18:30:55 UTC 2016


There are also rp-initiated use cases around suspected fraud, parallel
authentication of a second factor, and issuance of a consent receipt.

On Aug 11, 2016 12:27 PM, "Phil Hunt (IDM)" <phil.hunt at oracle.com> wrote:

> Sarah,
>
> Good question!
>
> Your use case is really the app initiated logout or logout within the
> context of a single application.
>
> If the app initiated front/ backchannel you would be saying log user out
> of all sso sites for that OP.
>
> If instead, the app issued the event to the OP, it would be saying the
> user was logged out of the app. Thus issuer is the app. The OP may or may
> not take action depending on its policy.
>
> We need to explore the use case.
>
> Talking through use cases was part of my reluctance to rushing id token
> without forming a wg.
>
> Phil
>
> On Aug 11, 2016, at 11:09 AM, Sarah Squire <sarah at engageidentity.com>
> wrote:
>
> 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.n
>> et 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/logou
>> t” 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/c5616ee8/attachment-0001.html>


More information about the Openid-specs-ab mailing list