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.
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
Thanks, Sergey
*From:*Justin Richer [mailto:[email protected]]
*Sent:* Tuesday, April 12, 2016 5:46 AM
*To:* Torsten Lodderstadt <[email protected]>
*Cc:* Anthony Nadalin <[email protected]>; <[email protected]>
<[email protected]>
*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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>>:
So it’s an incomplete solution then ?
*From:*Brian Campbell [mailto:[email protected]]
*Sent:*Monday, April 11, 2016 1:34 PM
*To:*Anthony Nadalin <[email protected]
<mailto:[email protected]>>
*Cc:*Nat Sakimura <[email protected]
<mailto:[email protected]>>; <[email protected]
<mailto:[email protected]>> <[email protected] <mailto:[email protected]>>
*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
<[email protected] <mailto:[email protected]>> 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:[email protected]
<mailto:[email protected]>]*On Behalf Of*Brian Campbell
*Sent:*Monday, April 11, 2016 12:30 PM
*To:*Nat Sakimura <[email protected]
<mailto:[email protected]>>
*Cc:*<[email protected] <mailto:[email protected]>>
<[email protected] <mailto:[email protected]>>
*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
<[email protected] <mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>>:
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
<[email protected] <mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>> 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
>>[email protected] <mailto:[email protected]>
>>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
>[email protected] <mailto:[email protected]>
>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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
