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 <prateek.mis...@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 <jric...@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 <
> hannes.tschofe...@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/
> >>
> >> 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
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > 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
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
