Sorry for a tardy reply. I was very much under the water till today. While your mental model works and is kind of stated in the introduction, it does not seem to be codified in the draft in a normative language. Perhaps doing so would be a good idea.
Even if the introspection endpoint is to be strongly bound to the AS, I am not sure if that is sufficient to establish an one-to-one relationship between the Introspection EP and the AS. Stating it normatively might be needed after all. If it is not the case, and one-to-many is allowed, then we probably should think a bit about the consequence of token swap attack etc. In the one-to-many scenario, "iss" gets more important, as the unique user_id will become indeterminate. I was actually thinking of one-to-many model when I wrote the first email since I was thinking of the "generic token decryption" service etc. If this spec is just for one-to-one case, then another spec probably is needed to achieve such. However, IMHO, it would be easier just to add "iss" so that this draft becomes more generic. Nat 2014-07-04 20:50 GMT+09:00 Justin Richer <jric...@mit.edu>: > And now with the list copied... > > > > -------- Original Message -------- Subject: Re: [OAUTH-WG] New Token > Introspection Draft Date: Fri, 04 Jul 2014 07:50:18 -0400 From: Justin > Richer <jric...@mit.edu> <jric...@mit.edu> To: Nat Sakimura > <sakim...@gmail.com> <sakim...@gmail.com> > > Interesting question. In my mental model of how this works, you're > asking the same AS that issued the token, so the "iss" is kindof a given > if the token is valid. Would there be a use for the server echoing that > back explicitly? Would people be using an introspection server that can > handle multiple issuers? I'm not against adding it, I simply didn't see > a use for it. > > Another data point: In our deployments of this, we're actually sending > out JWT formatted tokens that contain "iss" and a couple other fields. > The clients who care to do so check the "iss" field and the signature > themselves, but use introspection to find out which user this token was > issued to, what scopes it has, and all that detailed info. Some RS's > need it, some don't care. > > -- Justin > > On 7/4/2014 6:15 AM, Nat Sakimura wrote: > > Thanks Justin. > > > > Is there any reason that there is no iss claim returned? > > > > =nat via iPhone > > > >> On Jul 4, 2014, at 9:10, Justin Richer <jric...@mit.edu> <jric...@mit.edu> > >> wrote: > >> > >> I’ve updated the token introspection draft with the intention that this > >> document become input for a new working group item. > >> > >> http://tools.ietf.org/html/draft-richer-oauth-introspection-05 > >> > >> The changes are mostly minimal edits to the text and a few reference > >> fixes. One bigger change is the addition of the “user_id” field in > >> addition to the “sub” field, as I’ve been asked by some users to add that > >> feature to our own implementation here. > >> > >> ― Justin > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
