<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>+1 to this.</p>
<p>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. <br>
</p>
<p>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.</p>
<p> -- Justin<br>
</p>
<br>
<div class="moz-cite-prefix">On 8/11/2016 2:54 PM, Marius Scurtescu
via Openid-specs-ab wrote:<br>
</div>
<blockquote
cite="mid:CAGdjJp+YbxT+YyR0OYfJSAmA=-kJhDmVTf2V063_NMOtx9xaxQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">Can we step back and look at all the requirements
mentioned in this thread and see if we can simplify them:
<div>1. Multiple events per SET (Security Event Token).</div>
<div>2. SET issuer different from event issuer.</div>
<div>3. Existing Id Token parsers must not confuse a SET for an
Id Token.</div>
<div>4. Nested token format.</div>
<div><br>
</div>
<div>4 is needed by 1.</div>
<div>4 can fulfill 3, if sub can be present only in nested
events.<br>
</div>
<div><br>
</div>
<div>I don't think 1 is really needed, but with 4 it comes
really easy.</div>
<div><br>
</div>
<div>A nested format with sub only at event level seems to meet
all the requirements.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br clear="all">
<div>
<div class="gmail_signature" data-smartmail="gmail_signature">Marius</div>
</div>
<br>
<div class="gmail_quote">On Thu, Aug 11, 2016 at 11:30 AM, Sarah
Squire <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sarah@engageidentity.com" target="_blank">sarah@engageidentity.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir="ltr">There are also rp-initiated use cases around
suspected fraud, parallel authentication of a second
factor, and issuance of a consent receipt.</p>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Aug 11, 2016 12:27 PM,
"Phil Hunt (IDM)" <<a moz-do-not-send="true"
href="mailto:phil.hunt@oracle.com" target="_blank">phil.hunt@oracle.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>Sarah,</div>
<div><br>
</div>
<div>Good question!</div>
<div><br>
</div>
<div>Your use case is really the app initiated
logout or logout within the context of a
single application. </div>
<div><br>
</div>
<div>If the app initiated front/ backchannel you
would be saying log user out of all sso sites
for that OP. </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>We need to explore the use case. </div>
<div><br>
</div>
<div>Talking through use cases was part of my
reluctance to rushing id token without forming
a wg. <br>
<br>
Phil</div>
<div><br>
On Aug 11, 2016, at 11:09 AM, Sarah Squire
<<a moz-do-not-send="true"
href="mailto:sarah@engageidentity.com"
target="_blank">sarah@engageidentity.com</a>>
wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<p dir="ltr">Are we including use cases
where the RP is the event issuer?</p>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Aug 11, 2016
11:02 AM, "Mike Jones" <<a
moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com"
target="_blank">Michael.Jones@microsoft.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex">
<div link="blue" vlink="purple"
lang="EN-US">
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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!</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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: “</span>so
that all event specs can use it<span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">”.
The purpose of the logout
event *<b>isn’t</b>* 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 *<b>always</b>*
contain information that’s
specific to their use case.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.</span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> <wbr>
-- Mike</span></p>
<p class="MsoNormal"><a
moz-do-not-send="true"
name="m_-8168088028950720856_m_4477680742660022366_m_-6902039538064361870__MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></a></p>
<span></span>
<div>
<div
style="border:none;border-top:solid
#e1e1e1 1.0pt;padding:3.0pt
0in 0in 0in">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
Phil Hunt [mailto:<a
moz-do-not-send="true"
href="mailto:phil.hunt@oracle.com"
target="_blank">phil.hunt@oracle.com</a>]
<br>
<b>Sent:</b> Thursday,
August 11, 2016 12:49 PM<br>
<b>To:</b> Mike Jones <<a
moz-do-not-send="true"
href="mailto:Michael.Jones@microsoft.com"
target="_blank">Michael.Jones@microsoft.com</a>><br>
<b>Cc:</b> John Bradley
<<a
moz-do-not-send="true"
href="mailto:ve7jtb@ve7jtb.com"
target="_blank">ve7jtb@ve7jtb.com</a>>;
<a moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid" target="_blank">openid-specs-ab@lists.openid</a>.n<wbr>et
Ab <<a
moz-do-not-send="true"
href="mailto:openid-specs-ab@lists.openid"
target="_blank">openid-specs-ab@lists.openid</a>.<wbr>net>;
<a moz-do-not-send="true"
href="mailto:id-event@ietf.org" target="_blank">id-event@ietf.org</a>;
Marius Scurtescu <<a
moz-do-not-send="true"
href="mailto:mscurtescu@google.com"
target="_blank">mscurtescu@google.com</a>><br>
<b>Subject:</b> Re:
[Id-event] Summarizing
recent discussions on
ID-Event token draft</span></p>
</div>
</div>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Mike, </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">If you want
sub at the top level, that
would mean that the OIDC spec
format would have to look
like:</p>
</div>
<div>
<div>
<p class="MsoNormal">{</p>
</div>
<div>
<p class="MsoNormal"> "iss":
"<a moz-do-not-send="true"><span
style="color:purple">https://event.example.com</span></a>",</p>
</div>
<div>
<p class="MsoNormal"> "aud":
"s6BhdRkqt3",</p>
</div>
<div>
<p class="MsoNormal"> "jti":
"3d0c3cf797584bd193bd0fb1bd4e7<wbr>d30",</p>
</div>
<div>
<p class="MsoNormal"> <span
style="color:#b51a00">"sub":
“<a moz-do-not-send="true">https://token.example.com/248<wbr>289761001</a>",</span></p>
</div>
<div>
<p class="MsoNormal"> "iat":
1458668180,</p>
</div>
<div>
<p class="MsoNormal"> "exp":
1458668580,</p>
</div>
<div>
<p class="MsoNormal">
"events": [</p>
</div>
<div>
<p class="MsoNormal"> "<a
moz-do-not-send="true"><span
style="color:purple">https://specs.openid.net/logo<wbr>ut</span></a>"</p>
</div>
<div>
<p class="MsoNormal"> ],</p>
</div>
<div>
<p class="MsoNormal"> "sid":
"08a5019c-17e1-4977-8f42-65a12<wbr>843ea02"</p>
</div>
<div>
<p class="MsoNormal">}</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Given
that events are signed (or
should be), <u>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</u>.
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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">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.</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="color:black">Phil</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="color:black"> </span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="color:black">@independentid</span></p>
</div>
<div>
<p
class="MsoNormal"><span
style="color:black"><a moz-do-not-send="true">www.independentid.com</a></span></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"><span
style="color:black"><a
moz-do-not-send="true">phil.hunt@oracle.com</a></span></p>
</div>
<div>
<p class="MsoNormal"><span
style="color:black"> </span></p>
</div>
</div>
<p class="MsoNormal"><span
style="color:black"> </span></p>
</div>
<p class="MsoNormal"
style="margin-bottom:12.0pt"> </p>
</div>
<p class="MsoNormal"> </p>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On
Aug 11, 2016, at 9:32
AM, Mike Jones <<a
moz-do-not-send="true">Michael.Jones@microsoft.com</a>>
wrote:</p>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.</span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.</span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> <wbr>
-- Mike</span></p>
</div>
<div>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
<div>
<div
style="border:none;border-top:solid
#e1e1e1
1.0pt;padding:3.0pt
0in 0in 0in">
<div>
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">John
Bradley [<a
moz-do-not-send="true">mailto:ve7jtb@ve7jtb.com</a>]<span> </span><br>
<b>Sent:</b><span> </span>Thursday,
August 11, 2016
12:22 PM<br>
<b>To:</b><span> </span>Phil
Hunt (IDM) <<a
moz-do-not-send="true">phil.hunt@oracle.com</a>><br>
<b>Cc:</b><span> </span>Mike
Jones <<a
moz-do-not-send="true">Michael.Jones@microsoft.com</a>>;
<a
moz-do-not-send="true">id-event@ietf.org</a>;
Marius Scurtescu
<<a
moz-do-not-send="true">mscurtescu@google.com</a>>;
<a
moz-do-not-send="true">openid-specs-ab@lists.openid.n<wbr>et</a>
Ab <<a
moz-do-not-send="true">openid-specs-ab@lists.openid.<wbr>net</a>><br>
<b>Subject:</b><span> </span>Re:
[Id-event]
Summarizing
recent
discussions on
ID-Event token
draft</span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Not
surprisingly a
multipurpose message
format will not be as
optimized as a single
purpose one.</p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I
think the two
directions lead to
different formats.
</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">The
compromise of
special casing
Connect SLO and
bodging the formats
together is probably
the worst option.</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">John
B.</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p
class="MsoNormal">On
Aug 11, 2016,
at 11:59 AM,
Phil Hunt
(IDM) <<a
moz-do-not-send="true"><span
style="color:purple">phil.hunt@oracle.com</span></a>> wrote:</p>
</div>
</div>
<div>
<p
class="MsoNormal"> </p>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">How
do you resolve
conflicts on
iss then? The
top level has
to be the
issuer of the
event as the
issuer signs. </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">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. </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">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. </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"> </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Why
not have a
logout be an
event with an
id token
attached for
example?</span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
Phil</span></p>
</div>
</div>
<div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt"><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
On Aug 11,
2016, at 8:03
AM, Mike Jones
<<a
moz-do-not-send="true"><span
style="color:purple">Michael.Jones@microsoft.com</span></a>> wrote:</span></p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt;text-align:start;word-spacing:0px">
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.</span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">The
complexity
arises if
“sub” is
unnecessarily
special-cased. We shouldn’t do that, because it limits the
applicability
of the
specification.</span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> <wbr>
-- Mike</span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
<div>
<div
style="border:none;border-top:solid
#e1e1e1
1.0pt;padding:3.0pt
0in 0in 0in">
<div>
<div>
<p
class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Phil
Hunt (IDM) [<a
moz-do-not-send="true"><span style="color:purple">mailto:phil.hunt@oracle.com</span></a>]<span> </span><br>
<b>Sent:</b><span> </span>Thursday,
August 11,
2016 9:40 AM<br>
<b>To:</b><span> </span>Mike
Jones <<a
moz-do-not-send="true"><span
style="color:purple">Michael.Jones@microsoft.com</span></a>><br>
<b>Cc:</b><span> </span>Marius
Scurtescu <<a
moz-do-not-send="true"><span style="color:purple">mscurtescu@google.com</span></a>>;<span> </span><a
moz-do-not-send="true"><span style="color:purple">id-ev<wbr>ent@ietf.org</span></a><br>
<b>Subject:</b><span> </span>Re:
[Id-event]
Summarizing
recent
discussions on
ID-Event token
draft</span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">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. </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">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. </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">I
plan to post a
new draft
shortly that
will give some
examples based
on feedback
from the
openid
risc/connect
discussions.</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">We
can always
change again. </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><br>
Phil</p>
</div>
</div>
</div>
<div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt"><br>
On Aug 11,
2016, at 4:54
AM, Mike Jones
<<a
moz-do-not-send="true"><span
style="color:purple">Michael.Jones@microsoft.com</span></a>> wrote:</p>
</div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.</span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">There
are probably
use cases for
multiple
events per
message but I
doubt there
are use cases
for multiple *<b>unrelated</b>*
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.</span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">That
being said,
the
predominant
use case is
likely to be a
single event
per JWT.</span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> <wbr> <wbr>
-- Mike</span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Marius
Scurtescu [<a
moz-do-not-send="true"><span style="color:purple">mailto:mscurtescu@google.com</span></a>]<span><wbr> </span><br>
<b>Sent:</b><span> </span>Tuesday,
August 9, 2016
7:15 PM<br>
<b>To:</b><span> </span>Phil
Hunt <<a
moz-do-not-send="true"><span
style="color:purple">phil.hunt@oracle.com</span></a>><br>
<b>Cc:</b><span> </span>Mike
Jones <<a
moz-do-not-send="true"><span
style="color:purple">Michael.Jones@microsoft.com</span></a>>;<span><wbr> </span><a
moz-do-not-send="true"><span style="color:purple">id-event@ietf.org</span></a><br>
<b>Subject:</b><span> </span>Re:
[Id-event]
Summarizing
recent
discussions on
ID-Event token
draft</span></p>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">Mike,
are you
suggesting
that a sub
claim can only
show up at the
event level
and not at the
top level:</p>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc
1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p
class="MsoNormal">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.</p>
</div>
</div>
</blockquote>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">A
top level sub
and multiple
events are
incompatible
IMO.</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">Do
we have a
compelling
reason to
support
multiple
events per
message?</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><br
clear="all">
</p>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">Marius</p>
</div>
</div>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">On
Tue, Aug 9,
2016 at 12:39
PM, Phil Hunt
<<a
moz-do-not-send="true"><span
style="color:purple">phil.hunt@oracle.com</span></a>> wrote:</p>
</div>
</div>
<blockquote
style="border:none;border-left:solid
#cccccc
1.0pt;padding:0in
0in 0in
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<div>
<p
class="MsoNormal">I
was referring
to this in
your email</p>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">"<span
style="font-size:11.5pt;font-family:"Calibri",sans-serif;color:#002060">Define
that an event
name can be
used as a
top-level
claim”</span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">Is
this different
from the event
uri?</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">Phil</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">@independentid</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><a
moz-do-not-send="true"><span style="color:purple">www.independentid.com</span></a></p>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"><a
moz-do-not-send="true"><span style="color:purple">phil.hunt@oracle.com</span></a></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt"> </p>
</div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p
class="MsoNormal">On
Aug 9, 2016,
at 12:12 PM,
Mike Jones
<<a
moz-do-not-send="true"><span
style="color:purple">Michael.Jones@microsoft.com</span></a>> wrote:</p>
</div>
</div>
</div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.</span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">I’m
not sure what
you mean by “</span>I’m
not sure that
we need a
“name”. What
is your
intention
there.<span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">”
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 “<a
moz-do-not-send="true"><span style="color:purple">http://specs.openid.net/logou<wbr>t</span></a>”
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<span> </span></span><span
style="font-size:11.0pt;font-family:Wingdings;color:#002060">J</span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">.)</span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> <wbr>
Thanks again,</span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> <wbr>
-- Mike</span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><a
moz-do-not-send="true"
name="m_-8168088028950720856_m_4477680742660022366_m_-6902039538064361870_m_-6534435573639673786__MailEndCompose"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></a><span></span></p>
</div>
</div>
</div>
<div>
<div
style="border:none;border-top:solid
#e1e1e1
1.0pt;padding:3.0pt
0in 0in 0in">
<div>
<div>
<div>
<p
class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Phil
Hunt [<a
moz-do-not-send="true"><span
style="color:purple">mailto:phil.hunt@oracle.com</span></a>]<span> </span><br>
<b>Sent:</b><span> </span>Tuesday,
August 9, 2016
12:07 PM<br>
<b>To:</b><span> </span>Mike
Jones <<a
moz-do-not-send="true"><span
style="color:purple">Michael.Jones@microsoft.com</span></a>><br>
<b>Cc:</b><span> </span><a
moz-do-not-send="true"><span style="color:purple">id-event@ietf.org</span></a><br>
<b>Subject:</b><span> </span>Re:
[Id-event]
Summarizing
recent
discussions on
ID-Event token
draft</span></p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal">I
didn’t cover
this as I
didn’t want to
confuse people
with too many
things.</p>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">But
I think we
agree on all
of the below.</p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">I’m
not sure that
we need a
“name”. What
is your
intention
there.</p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">Phil</p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">@independentid</p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><a
moz-do-not-send="true"><span style="color:purple">www.independentid.com</span></a></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"><a
moz-do-not-send="true"><span style="color:purple">phil.hunt@oracle.com</span></a></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<p
class="MsoNormal"
style="margin-bottom:12.0pt"> </p>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<blockquote
style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<div>
<p
class="MsoNormal">On
Aug 9, 2016,
at 11:54 AM,
Mike Jones
<<a
moz-do-not-send="true"><span
style="color:purple">Michael.Jones@microsoft.com</span></a>> wrote:</p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.)</span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">I
believe that
the ID Events
spec needs to
include these
things, and
these things
only:</span></p>
</div>
</div>
</div>
</div>
<div
style="margin-left:.5in">
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:Symbol;color:#002060">·</span><span
style="font-size:7.0pt;color:#002060"> <span> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">Define
of the
“events” claim</span></p>
</div>
</div>
</div>
</div>
<div
style="margin-left:.5in">
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:Symbol;color:#002060">·</span><span
style="font-size:7.0pt;color:#002060"> <span> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">Define
that an event
name can be
used as a
top-level
claim</span></p>
</div>
</div>
</div>
</div>
<div
style="margin-left:.5in">
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:Symbol;color:#002060">·</span><span
style="font-size:7.0pt;color:#002060"> <span> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">Require
that “iss” be
included and
that the JWT
be signed by
the issuer</span></p>
</div>
</div>
</div>
</div>
<div
style="margin-left:.5in">
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:Symbol;color:#002060">·</span><span
style="font-size:7.0pt;color:#002060"> <span> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">Include
a statement
along the
lines of “The
claims to be
included with
any particular
event are to
be defined by
the event”</span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">And
I’d stop
there.</span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.</span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060">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.”</span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> <wbr>
-- Mike</span></p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#002060"> </span></p>
</div>
</div>
</div>
</div>
<div>
<div
style="border:none;border-top:solid
#e1e1e1
1.0pt;padding:3.0pt
0in 0in 0in">
<div>
<div>
<div>
<div>
<p
class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span></span><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">Id-event
[<a
moz-do-not-send="true"><span
style="color:purple">mailto:id-event-bounces@ietf.<wbr>org</span></a>]<span> </span><b>On
Behalf Of<span> </span></b>Phil
Hunt<br>
<b>Sent:</b><span> </span>Tuesday,
August 9, 2016
10:19 AM<br>
<b>To:</b><span> </span><a
moz-do-not-send="true"><span style="color:purple">id-event@ietf.org</span></a><br>
<b>Subject:</b><span> </span>[Id-event]
Summarizing
recent
discussions on
ID-Event token
draft</span></p>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">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.</p>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">These
discussions
have been
about the core
spec and the
role of
“top-level”
attributes vs.
event
“extension”
attributes. </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">See:<span> </span><a
moz-do-not-send="true"><span style="color:purple">https://tools.ietf.org/ht<wbr>ml/draft-hunt-idevent-token-01</span></a></p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">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. </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">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. </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">To
summarize a
fair amount of
discussion,
the feeling
seems to be
the following:</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">*
The Event
Token top
level
attributes
should be
fairly limited
and not
include the
sub attribute.
</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">*
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. </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">*
The top-level
“iss” shall
mean the
issuer of the
event where
the state
change
occurred.</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">*
“sub” should
not be present
in the top
level
structure.
Also, “events”
must also be
present.</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p
class="MsoNormal">Here
would be a new
example
logout:</p>
</div>
</div>
</div>
</div>
</div>
<div>
<pre>{</pre>
<pre> <— top level is about the event itself -></pre>
<pre> <span style="color:#5e30eb">"iss": "<a moz-do-not-send="true"><span style="color:purple">https://server.example.com</span></a>",</span></pre>
<pre><span style="color:#5e30eb"> "aud": "s6BhdRkqt3",</span></pre>
<pre><span style="color:#5e30eb"> "jti": "3d0c3cf797584bd193bd0fb1bd4e7<wbr>d30",</span></pre>
<pre><span style="color:#5e30eb"> "iat": 1458668180,</span></pre>
<pre><span style="color:#5e30eb"> "exp": 1458668580,</span></pre>
<pre><span style="color:#5e30eb"> "events": [</span></pre>
<pre><span style="color:#5e30eb"> "<a moz-do-not-send="true"><span style="color:purple">https://specs.openid.net/logo<wbr>ut</span></a>"</span></pre>
<pre><span style="color:#5e30eb"> ],</span></pre>
<pre> <span style="color:#e63b7a"> "<a moz-do-not-send="true"><span style="color:purple">https://specs.openid.net/log<wbr>out</span></a>": {</span></pre>
<pre><span style="color:#e63b7a"> <- This level is defined entirely by the event URI-></span></pre>
<pre><span style="color:#e63b7a"> "iss": "<a moz-do-not-send="true"><span style="color:purple">https://oidc.example.com</span></a>",</span></pre>
<pre><span style="color:#e63b7a"> “jti": "08a5019c-17e1-4977-8f42-65a12<wbr>843ea02”,</span></pre>
<pre><span style="font-size:12.0pt;color:#e63b7a"> "sub": "248289761001”,</span></pre>
<pre><span style="font-size:12.0pt;color:#e63b7a"> “exp”: <ID token expiry></span></pre>
<pre><span style="font-size:12.0pt;color:#e63b7a"> }</span></pre>
<pre><span style="font-size:12.0pt">}</span></pre>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">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).</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">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.</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Phil</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">@independentid</p>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><a moz-do-not-send="true"><span style="color:purple">www.independentid.com</span></a></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><a moz-do-not-send="true"><span style="color:purple">phil.hunt@oracle.com</span></a></p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">______________________________<wbr>_________________
Id-event mailing list
</span><a moz-do-not-send="true"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">Id-event@ietf.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">
</span><a moz-do-not-send="true"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:purple">https://www.ietf.org/mailman/l<wbr>istinfo/id-event</span></a></p>
</div>
</div>
</div>
</blockquote>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt">
______________________________<wbr>_________________
Id-event mailing list
<a moz-do-not-send="true"><span style="color:purple">Id-event@ietf.org</span></a>
<a moz-do-not-send="true"><span style="color:purple">https://www.ietf.org/mailman/l<wbr>istinfo/id-event</span></a></p>
</blockquote>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal">______________________________<wbr>_________________
Id-event mailing list
<a moz-do-not-send="true"><span style="color:purple">Id-event@ietf.org</span></a>
<a moz-do-not-send="true"><span style="color:purple">https://www.ietf.org/mailman/l<wbr>istinfo/id-event</span></a></p>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">______________________________<wbr>_________________
Id-event mailing list
<a moz-do-not-send="true"><span style="color:purple">Id-event@ietf.org</span></a>
<a moz-do-not-send="true"><span style="color:purple">https://www.ietf.org/mailman/l<wbr>istinfo/id-event</span></a></span></p>
</div>
</div>
</blockquote>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">______________________________<wbr>_________________
Id-event mailing list
<a moz-do-not-send="true">Id-event@ietf.org</a>
<a moz-do-not-send="true">https://www.ietf.org/mailman/l<wbr>istinfo/id-event</a></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
______________________________<wbr>_________________
Id-event mailing list
<a moz-do-not-send="true" href="mailto:Id-event@ietf.org" target="_blank">Id-event@ietf.org</a>
<a moz-do-not-send="true" href="https://www.ietf.org/mailman/" target="_blank">https://www.ietf.org/mailman/</a>l<wbr>istinfo/id-event
</blockquote></div></div>
</div></blockquote></div></blockquote></div></div>
</div></div></blockquote></div>
</div>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre wrap="">_______________________________________________
Openid-specs-ab mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a>
<a class="moz-txt-link-freetext" href="http://lists.openid.net/mailman/listinfo/openid-specs-ab">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a>
</pre>
</blockquote>
</body></html>