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

Justin Richer jricher at mit.edu
Thu Aug 11 19:03:31 UTC 2016


+1 to this.

I'd also add that the "pass through" logic I mentioned in the other 
email fits this as well. Basically, if my event *doesn't* have a "sub", 
then I assume it's the same "sub" as the root object. But the lower 
level would always shadow the upper one, in the context of the event 
itself.

This is of course an optimization, but it allows for the kind of 
structures like Mike is talking about without things getting overly 
weird for the general case.

  -- Justin


On 8/11/2016 2:54 PM, Marius Scurtescu via Openid-specs-ab wrote:
> Can we step back and look at all the requirements mentioned in this 
> thread and see if we can simplify them:
> 1. Multiple events per SET (Security Event Token).
> 2. SET issuer different from event issuer.
> 3. Existing Id Token parsers must not confuse a SET for an Id Token.
> 4. Nested token format.
>
> 4 is needed by 1.
> 4 can fulfill 3, if sub can be present only in nested events.
>
> I don't think 1 is really needed, but with 4 it comes really easy.
>
> A nested format with sub only at event level seems to meet all the 
> requirements.
>
> Allowing different event specs to define top level claims, like sub, 
> is very problematic IMO because you can run into incompatible events. 
> Same with requiring that all events in a single token must refer to 
> the same sub. This can lead to very complex and buggy publisher 
> implementations.
>
>
>
> Marius
>
> On Thu, Aug 11, 2016 at 11:30 AM, Sarah Squire 
> <sarah at engageidentity.com <mailto:sarah at engageidentity.com>> wrote:
>
>     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
>     <mailto: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 <mailto: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
>>         <mailto: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
>>             <mailto:phil.hunt at oracle.com>]
>>             *Sent:* Thursday, August 11, 2016 12:49 PM
>>             *To:* Mike Jones <Michael.Jones at microsoft.com
>>             <mailto:Michael.Jones at microsoft.com>>
>>             *Cc:* John Bradley <ve7jtb at ve7jtb.com
>>             <mailto:ve7jtb at ve7jtb.com>>; openid-specs-ab at lists.openid
>>             <mailto:openid-specs-ab at lists.openid>.net Ab
>>             <openid-specs-ab at lists.openid
>>             <mailto:openid-specs-ab at lists.openid>.net>;
>>             id-event at ietf.org <mailto:id-event at ietf.org>; Marius
>>             Scurtescu <mscurtescu at google.com
>>             <mailto: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 confusionJ.)
>>
>>                                     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.orghttps://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 <mailto:Id-event at ietf.org>
>>             https://www.ietf.org/mailman/listinfo/id-event 
>>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20160811/8602f8c2/attachment-0001.html>


More information about the Openid-specs-ab mailing list