> -----Original Message-----
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Wednesday, August 17, 2011 1:13 PM
> > > 1.3/1.4/1.5: Consider switching order to Authorization Grant, Access
> > > Token, Refresh Token
> >
> > Not sure. What do others think? I put access token first because it is a
> > more
> important term to get out of the way.
>
> I agree that access tokens are a more important topic to OAuth overall, but
> the rest of the document presents things in protocol flow order: you get the
> auth grant, then you get the tokens.
Ok. I'll give it a try.
> > > 1.4.1: We probably want to mention a user agent here in the exposure
> > > risk at the end. Since that's really the problem -- the browser
> > > could steal the token, not the end user.
> >
> > Proposed text?
>
> The authorization code provides a few important security benefits
> such as the ability to authenticate the client and issuing the access
> token directly to the client without potentially exposing it to
> others, including the resource owner or other applications in the resource
> owner's user agent.
How about:
The authorization code provides a few important security benefits
such as the ability
to authenticate the client, and the transmission of the the access
token directly to
the client without passing it through the resource owner's
user-agnet, potentially
exposing it to others, including the resource owner.
> > > 2: Isn't "means" generally treated as singular in instances like this?
> > > Thus "means ... is" instead of "means ... are".
> >
> > Don't know.
>
> I think it is, unless someone can put a stake in to say that's wrong.
"It is plural when it refers to a group of strategies or methods"
> > > 2.1/2.2: The requirements (2.2) should go first in section 2. The
> > > client types are part of deciding the requirements, and the concepts flow
> better this way.
> >
> > You need to first define client types before you can require it.
>
> No you don't, you just need to reference them. You already don't define the
> other requirements until after (such as the redirection urls). I think it
> reads
> better to have the requirements up front, when the full matter of what
> they're all about in the following sections. The client As it is now, there
> are
> both forward and backward references in the requirements paragraph and
> it's confusing to read like that.
Ok.
> > > 2.4.2: Want to mention the MAC binding as an example here? This
> > > would parallel the OAuth2 method of signing the fetch for a request
> > > token more directly.
> >
> > Nah.
>
> Let me put it stronger: I would like to see an explicit reference to the MAC
> binding here as an example of a stronger auth binding, along with an
> example. OAuth1 allowed for binding against the token endpoint using a
> client secret that was not passed across the wire, and the MAC spec gives
> that capability to OAuth2. I would really like to see that.
>
> I see no problem in the core document pointing out the MAC and Bearer
> documents as prime examples where appropriate.
Pointing to the MAC specification in this context will be both confusing and
against the balance we have reached (with great effort) in how we discuss
authentication. No one is a bigger supporter of the MAC proposal than me... and
I rather avoid this reference, here.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
