I believe that depending on the resource server that scope is important for both the security layers and application function layers. For example, an application may wish to use scope as a set of entitlements. Does client have entitlement "readProfile".
It makes no sense to me to have a scope in the authorization request and then not make it available to the resource endpoint except via back channels. If that was the case why would I use anything other than an artifact? That said, I think scope is way underdefined. But that's another issue. Phil @independentid www.independentid.com [email protected] On 2013-02-28, at 9:56 AM, Hannes Tschofenig wrote: > I guess we first have to agree whether there is a security benefit of > communicating the scope from the AS to the RS (in a way that it cannot be > modified by the client or any other party). > > The scope indicates permissions (for example, whether the resource owner > allowed read access to a certain resource or write access). > > Do you agree that there is a security benefit (or to put it the other way > around: do you see the security vulnerability if this information is not > communicated to the RS and checked against what the resource owner accepted? > > Then, a secondary question is what the right mechanism is. > > Ciao > Hannes > > > On 02/28/2013 07:29 PM, Phil Hunt wrote: >> What people are doing now is often issuing saml like assertions. Thats not >> necessarily indicating intent. It just indicates transition. >> >> Phil >> >> Sent from my phone. >> >> On 2013-02-28, at 9:07, John Bradley <[email protected]> wrote: >> >>> I am not advocating anything, only sting what people are doing now. >>> >>> How authorization is communicated between the AS and RS via a token that is >>> opaque to the client is out of scope fro OAuth core, it might be magic pixy >>> dust. >>> >>> This has lead to a number of ways people are doing it. >>> >>> JWT along with JOSE provide a container to get some claims from the AS to >>> the RS though the JWT is not specific to this and is used in the assertions >>> profile and other specs for many things other than access tokens. >>> >>> Yes a profile of JWT for an access token as an access token is needed, Yes >>> further profiling is required for a JWT access token using MAC. >>> >>> The format of the authorization claims is not tightly bound to MAC and >>> might be used with other bearer JWT tokens. >>> >>> I don't know that there will be only one way to communicate those claims >>> because different sorts of implementations need different information for >>> the RS to act on. >>> Recommendations are fine but defining a field called scope and passing on >>> exactly the scopes the client was granted is not going to work for everyone >>> for lots of good reasons. >>> >>> John B. >>> On 2013-02-28, at 8:24 AM, Phil Hunt <[email protected]> wrote: >>> >>>> Are you advocating TWO systems? That seems like a bad choice. >>>> >>>> I would rather fix scope than go to a two system approach. >>>> >>>> Phil >>>> >>>> Sent from my phone. >>>> >>>> On 2013-02-28, at 8:17, John Bradley <[email protected]> wrote: >>>> >>>>> While scope is one method that a AS could communicate authorization to a >>>>> RS, it is not the only or perhaps even the most likely one. >>>>> Using scope requires a relatively tight binding between the RS and AS, >>>>> UMA uses a different mechanism that describes finer grained operations. >>>>> The AS may include roles, user, or other more abstract claims that the >>>>> the client may (god help them) pass on to EXCML for processing. >>>>> >>>>> While having a scopes claim is possible, like any other claim it is not >>>>> part of the JWT core security processing claims, and needs to be defined >>>>> by extension. >>>>> >>>>> John B. >>>>> On 2013-02-28, at 2:29 AM, Hannes Tschofenig <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Mike, >>>>>> >>>>>> when I worked on the MAC specification I noticed that the JWT does not >>>>>> have a claim for the scope. I believe that this would be needed to allow >>>>>> the resource server to verify whether the scope the authorization server >>>>>> authorized is indeed what the client is asking for. >>>>>> >>>>>> Ciao >>>>>> Hannes >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
