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. <jric...@mitre.org> 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 <ve7...@ve7jtb.com> 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 <e...@xmlgrrl.com> 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 <ve7...@ve7jtb.com> 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. <jric...@mitre.org> 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 <wmills_92...@yahoo.com> 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." >>>>>> <jric...@mitre.org> 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 <wmills_92...@yahoo.com> 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." >>>>>>> <jric...@mitre.org> 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 <wmills_92...@yahoo.com> 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 >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
