On Wed, Dec 3, 2014 at 3:37 AM, <[email protected]> wrote:
> Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/oauth > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of OAuth digest..." > > > Today's Topics: > > 1. Re: Review of draft-ietf-oauth-introspection-01 (Justin Richer) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 02 Dec 2014 20:36:59 -0500 > From: Justin Richer <[email protected]> > To: Phil Hunt <[email protected]> > Cc: "[email protected]" <[email protected]> > Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 > Message-ID: <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Ah, I think I got my threads crossed. Then yes, I agree with you, and I'm > going to be making authorization a MUST instead of a SHOULD. Would love to > hear feedback from other implementers on this point.? > > > -- Justin > > / Sent from my phone / > > > -------- Original message -------- > From: Phil Hunt <[email protected]> > Date:12/02/2014 8:25 PM (GMT-05:00) > To: Justin Richer <[email protected]> > Cc: [email protected] > Subject: Re: [OAUTH-WG] Review of draft-ietf-oauth-introspection-01 > > I was asking in the context of the thread where the comment was made that > you only need to authenticate if more information is provided. > > This didn?t make sense to me. Because you would never make the call to > re-confirm (pointless). Even a caller re-confirming is actually checking > for more information - to see if the assertion has been revoked. > > Phil > > @independentid > www.independentid.com > [email protected] > > On Dec 2, 2014, at 5:04 PM, Justin Richer <[email protected]> wrote: > > Nothing says you need to pack the same information inside the JWT that you > return from introspection. In our specific case, we don't put scopes or > client IDs inside the JWT, just basic signature/identifier type stuff, so > you need to call introspection to get back this other information. But the > information inside the JWT includes an "iss" claim which the client can use > to figure out *which* introspection endpoint to call. > > This is just one of many different ways you could handle multiple AS at a > single resource, and so it's definitely orthogonal to the basic > introspection concept. > > -- Justin > > On 12/2/2014 6:38 PM, Phil Hunt wrote: > I am confused. Why would you call the introspection endpoint if you were > not expecting new information to be disclosed? > > Phil > > On Dec 2, 2014, at 14:26, Richer, Justin P. <[email protected]> wrote: > > I agree that there's some use in this (and in fact I've deployed a version > that uses a signed JWT to indicate its authorization server), but it should > remain outside the scope of this spec. It's a service discovery problem, > it's orthogonal. > > -- Justin > > > On Dec 2, 2014, at 5:13 PM, John Bradley <[email protected]> wrote: > > Yes, but unless there is something new the introspection endpoint in UMA > is tied to the resource. > > In some cases having the token indicate the introspection endpoint may be > useful. > > John B. > > Sent from my iPhone > > On Dec 2, 2014, at 10:02 PM, Eve Maler <[email protected]> wrote: > > FWIW, UMA goes ahead and standardizes a good deal about the trust > establishment between the RS and the AS, and (of course) profiles and wraps > the token introspection spec as part of the resulting ?authorization API? > that the AS presents to the RS. A big part of the motivation for this is to > support an n:n relationship between AS and RS entities. > > EVe > > On 2 Dec 2014, at 12:14 PM, John Bradley <[email protected]> wrote: > > Many of the proprietary introspection protocols in use return scope, role > or other meta data for the RS to make its access policy decision on. > One of the reasons for using opaque tokens rather than JWT is to prevent > leakage of that info. > > Making authentication to the introspection endpoint a MUST if additional > attributes are present is OK, I might even be inclined to say that > authentication of some sort is always required, but that might be going a > bit far for some use cases. > > We have a lot of proprietary ways to do this from IBM, Layer 7, Ping etc. > It would be nice if we could standardize it. Precluding other attributes > would not be helpful for adoption. > > > One issue that we haven?t addressed in this spec is what happens if there > are multiple AS for the RS and how it would decide what introspection > endpoint to use. > Perhaps that needs to be a extension, leaving this for the simple case. > > However having more than on e AS per RS is not as unusual as it once was > in larger environments. > > John B. > > > On Dec 2, 2014, at 4:56 PM, Richer, Justin P. <[email protected]> wrote: > > Agreed, which is why we've got space for the "sub" and "user_id" fields > but not anything else about the user, and we've got a privacy > considerations section for dealing with that. If you can help make the > wording on that section stronger, I'd appreciate it. > > -- Justin > > On Dec 2, 2014, at 2:25 PM, Bill Mills <[email protected]> wrote: > > If introspection returns any other user data beyond what is strictly > required to validate the token based solely on possession of the public > part it would be a mistake. > > > On Tuesday, December 2, 2014 11:13 AM, "Richer, Justin P." < > [email protected]> wrote: > > > That's all fine -- it's all going over TLS anyway (RS->AS) just like the > original token fetch by the client (C->AS). Doesn't mean you need TLS > *into* the RS (C->RS) with a good PoP token. > > Can you explain how this is related to "act on behalf of"? I don't see any > connection. > > -- Justin > > On Dec 2, 2014, at 2:09 PM, Bill Mills <[email protected]> wrote: > > Fetching the public key for a token might be fine, but what if the > introspection endpoint returns the symmetric key? Data about the user? > Where does this blur the line between this and "act on behalf of"? > > > On Tuesday, December 2, 2014 11:05 AM, "Richer, Justin P." < > [email protected]> wrote: > > > The call to introspection has a TLS requirement, but the call to the RS > wouldn't necessarily have that requirement. The signature and the token > identifier are two different things. The identifier doesn't do an attacker > any good on its own without the verifiable signature that's associated with > it and the request. What I'm saying is that you introspect the identifier > and get back something that lets you, the RS, check the signature. > > -- Justin > > On Dec 2, 2014, at 1:40 PM, Bill Mills <[email protected]> wrote: > > "However, I think it's very clear how PoP tokens would work. ..." > > I don't know if that's true. POP tokens (as yet to be fully defined) would > then also have a TLS or transport security requirement unless there is > token introspection client auth in play I think. Otherwise I can as an > attacker take that toklen and get info about it that might be useful, and I > don't think that's what we want. > > -bill > > > > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > Eve Maler http://www.xmlgrrl.com/blog > +1 425 345 6756 http://www.twitter.com/xmlgrrl > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/oauth/attachments/20141202/97e34bdb/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > ------------------------------ > > End of OAuth Digest, Vol 74, Issue 31 > ************************************* >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
