On Tue, Apr 12, 2016 at 9:24 AM, Sergey Beryozkin <***@gmail.com>
wrote:
> Hi
> On 12/04/16 14:03, Anthony Nadalin wrote:
>
>> Specifications should be somewhat complete and not open ended/not
>> thought out, you should think about the issues, requirements and use
>> cases first before you try to force this into the working group process
>> and confuse people , we had too many of these specifications lately.
>>
>> I'm not an expert yet I'm not consider myself confused :-). It is a basic
> incremental improvement, trying to come up with a standard approach toward
> restricting tokens to very specific resource servers.
Yes, so basically you have a refresh token with scopes A & B. You want to
get an access token for use at Resource Server 1 (RS1) with only scope A,
then one for Resource Server 2 (RS2) with only scope B, so you would refresh
<https://tools.ietf.org/html/rfc6749#section-6> the token stating
scope=A&resource=RS1, and then scope=B&resource=RS2. OAuth already
supports the ability to request a scope sub-set during refresh, Brian's
spec adds the ability to indicate what RS you intend to use the resulting
access token at.
This topic has also came up in the context of Token Binding which is one
place where it is relevant to have RS-specific tokens, and I had the
impression from that meeting that some method of specifying the intended
resource would be helpful.
This is a really simple proposal that just standardizes that pattern so
people don't try to jam everything but the kitchen sink into 'scope'.
> We are now up to 15+ specifications that someone has to read and
>> understand how these all may or may not fit together and all the
>> interactions that may occur. So much for the simple Oauth.
>>
>
> This particular text is simpler than a token exchange draft :-).
>
> By the way there was a proposal recently to have OAuth 2.1 document where
> the best practices/etc are suggested, I suppose that can help consolidate
> various texts created since original OAuth 2.0
>
At some point this may make sense, but I think for now the better
consolidated approach is online documentation and books
<https://www.manning.com/books/oauth-2-in-action>. Not everyone needs to
start at the RFC level.
As Mike Jones suggested earlier we should have some rounds of iteration and
get experience with the various extension specs before we attempt to merge
them together into 1 document. For example, it's likely that not all the
specs would get included in such a document and we need more deployment
experience to know what to include, and what not to.
> *From:*Justin Richer [mailto:***@mit.edu]
>> *Sent:* Tuesday, April 12, 2016 5:46 AM
>> *To:* Torsten Lodderstadt <***@lodderstedt.net>
>> *Cc:* Anthony Nadalin <***@microsoft.com>; <***@ietf.org>
>> <***@ietf.org>
>> *Subject:* Re: [OAUTH-WG] Call for Adoption: Resource Indicators for
>> OAuth 2.0
>>
>> +1 to Torstenâs point.
>>
>> And a reminder to Tony that call for adoption is the *start* of the
>> document editing process, not the end. Weâre not saying this is a
>> complete solution with everything thought out when we adopt the
>> document, weâre saying itâs a problem we want to work on and a direction
>> that we want to move in. Stop trying to confuse people.
>>
>> â Justin
>>
>> On Apr 12, 2016, at 1:30 AM, Torsten Lodderstedt
>> <***@lodderstedt.net <mailto:***@lodderstedt.net>> wrote:
>>
>> Indicating the resource server to the AS allows the AS to
>> automatically select token type, encryption scheme and user data to
>> be put into the access token based on a RS-specific policy. So there
>> is no need to explicitely ask the AS for a certain token format or
>> encryption scheme.
>>
>>
>> Am 11.04.2016 um 22:35 schrieb Anthony Nadalin
>> <***@microsoft.com <mailto:***@microsoft.com>>:
>>
>> So itâs an incomplete solution then ?
>>
>> *From:*Brian Campbell [mailto:***@pingidentity.com]
>> *Sent:*Monday, April 11, 2016 1:34 PM
>> *To:*Anthony Nadalin <***@microsoft.com
>> <mailto:***@microsoft.com>>
>> *Cc:*Nat Sakimura <***@gmail.com
>> <mailto:***@gmail.com>>; <***@ietf.org
>> <mailto:***@ietf.org>> <***@ietf.org <mailto:***@ietf.org>>
>> *Subject:*Re: [OAUTH-WG] Call for Adoption: Resource Indicators
>> for OAuth 2.0
>>
>> No, I'm not adding requirements for encryption. I was pointing
>> out some of the ways that an access token might be different for
>> different RSs.
>>
>>
>> On Mon, Apr 11, 2016 at 2:18 PM, Anthony Nadalin
>> <***@microsoft.com <mailto:***@microsoft.com>> wrote:
>>
>> So now you are adding more requirements for encryption ? The
>> more this thread goes on shows how unstable and not fully
>> thought out this draft is to go through WG adoption.
>>
>> *From:*OAuth [mailto:oauth-***@ietf.org
>> <mailto:oauth-***@ietf.org>]*On Behalf Of*Brian Campbell
>> *Sent:*Monday, April 11, 2016 12:30 PM
>> *To:*Nat Sakimura <***@gmail.com
>> <mailto:***@gmail.com>>
>> *Cc:*<***@ietf.org <mailto:***@ietf.org>>
>> <***@ietf.org <mailto:***@ietf.org>>
>> *Subject:*Re: [OAUTH-WG] Call for Adoption: Resource
>> Indicators for OAuth 2.0
>>
>> Sending a token type is not sufficient. There's more
>> involved than the format. Many cases need to know if to
>> encrypt and whom to encrypt to. What claims to put in the
>> token (or reference by the token). What algorithms and keys
>> to use for signing/encryption.
>>
>>
>> The statement that the "Current proposal does not support
>> the implicit flow" is incorrect. Among other things, sec 2
>> has, "When an access token will be returned from the
>> authorization endpoint, the "resource" parameter is used in
>> the authorization request to the authorization endpoint as
>> defined in Section 4.2.1 of OAuth 2.0 [RFC6749]."
>>
>> On Sun, Apr 10, 2016 at 11:43 AM, Nat Sakimura
>> <***@gmail.com <mailto:***@gmail.com>> wrote:
>>
>> So, my understanding on the rationale/requirements for
>> having this spec right now is:
>>
>> R1. Authz server wants toprevent the replay by the
>> server that received it.
>>
>> R2. Authz server needs to mint the access token in a
>> variety of format depending on the resource server and
>> to do that, you need to know which RS is gong to be
>> receiving it.
>>
>> To achieve R1, there are couple of methods. The proposed
>> method here is to audience restrict the token, but the
>> same can be achieved by sender constraining the token,
>> e.g., by token binding. As far as I can see, the
>> sentiment of the WG seems to be to use the sender
>> constraint through Token Binding, so from this respect,
>> this spec is not the one to do R1. Besides, the current
>> proposal only takes care of the code flow. The same
>> requirement should be there for implicit flow as well,
>> so the current proposal is not covering the R1 anyways.
>>
>> I can sort of understand R2, but I have two critique on
>> the current proposal:
>>
>> C1. Current proposal does not support the implicit flow.
>> To support it, the resource URI has to be sent to the
>> Authz endpoint instead of the Token endpoint.
>>
>> C2. It is much more direct to send the required token
>> format rather than the RS uri and probably better as:
>>
>> 1) There are use cases where the AS does not maintain
>> the list of RSs that it supports, e.g., AOL.
>>
>> In such a case, even if the RS uri were sent to
>> the AS, the AS cannot mint the tokens in the appropriate
>> format.
>>
>> 2) When it is sent in the Authz request, it is
>> leaking the information about the resource that the
>> client is going to the browser.
>>
>> 3) There are use cases where it is desirable not to
>> let the AS knows where the Client is going from the
>> privacy point of view.
>>
>> So, my suggestion is to drop R1 and concentrate on R2.
>> And to solve R2, send token type instead of the resource
>> indicator in the request.
>>
>> This also necessitates the Client to be able to find out
>> what token type the resource requires, perhaps in the
>> unauthorized response web link header at the resource in
>> the manner of oauth-meta.
>>
>> Cheers,
>>
>> Nat
>>
>> 2016幎4æ8æ¥(é) 8:23 Prateek Mishra
>> <***@oracle.com
>> <mailto:***@oracle.com>>:
>>
>> While this work addresses a gap in the existing
>> OAuth specification set, I am very concerned that this
>> incremental extension will lead to even more
>> confusion around the areas of âscopeâ, âaudienceâ
>> and âresource serverâ.
>>
>> I think we should try to solve this problem via a
>> framework that provides better guidance and
>> implementation
>> models for OAuth use-cases. In other words, I feel
>> that a broader discussion is needed here.
>>
>>
>> > On Apr 7, 2016, at 4:11 PM, Justin Richer
>> <***@mit.edu <mailto:***@mit.edu>> wrote:
>> >
>> > I support adoption of this document as a starting
>> point for working group work.
>> >
>> > â Justin
>> >
>> >
>> >> On Apr 6, 2016, at 1:25 PM, Hannes Tschofenig
>> <***@gmx.net
>> <mailto:***@gmx.net>> wrote:
>> >>
>> >> Hi all,
>> >>
>> >> this is the call for adoption of 'Resource
>> Indicators for OAuth 2.0', see
>> >>
>> http://datatracker.ietf.org/doc/draft-campbell-oauth-resource-indicators/
>> <
>> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fdatatracker.ietf.org%2fdoc%2fdraft-campbell-oauth-resource-indicators%2f&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=y869Fk9987ff09hvHIN%2bVGl%2fqxwWDmkvOwzcQcWqXZw%3d
>> >
>> >>
>> >> Please let us know by April 20th whether you
>> accept / object to the
>> >> adoption of this document as a starting point
>> for work in the OAuth
>> >> working group.
>> >>
>> >> Note: If you already stated your opinion at the
>> IETF meeting in Buenos
>> >> Aires then you don't need to re-state your
>> opinion, if you want.
>> >>
>> >> The feedback at the BA IETF meeting was the
>> following: ~10 persons
>> >> for accepting the document and 0 persons against.
>> >>
>> >> Ciao
>> >> Hannes & Derek
>> >>
>> >> _______________________________________________
>> >> OAuth mailing list
>> >>***@ietf.org <mailto:***@ietf.org>
>> >>https://www.ietf.org/mailman/listinfo/oauth
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> >***@ietf.org <mailto:***@ietf.org>
>> >https://www.ietf.org/mailman/listinfo/oauth
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c9590e4025eb6442ecede08d3623fc961%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=bfp1DGH5j%2btM4Ztx7M%2bueK7KxV6kNJEXZKHECIUKiBQ%3d
>> >
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d
>> >
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org <mailto:***@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>> <
>> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2foauth&data=01%7c01%7ctonynad%40microsoft.com%7c81244957f086491ed84508d362d07a2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=ApH6%2fbRs21OYURWWYx4N4lWVSeCI%2fAPj2eSOA3fdcTw%3d
>> >
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> ***@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
>
> _______________________________________________
> OAuth mailing list
> ***@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>