At IIW last week, myself, Biran Eaton from Google and Allen Tom from
Yahoo! presented what is now called OAuth WRAP
The specs and discussion specific to those documents is at:
We plan to submit the document as an I-D next week when I-D submission
is open again, and for further work to occur in the IETF OAuth WG.
OAuth mailing list
It seems to me that without simple guidelines on what's reasonable to be called "OAuth", anyone can propose a protocol that purports to be related in some way to OAuth, at the expense of community confusion and dilution of its meaning. Is there a way to mitigate this kind of occurrence other than by simply dismissing it as noise?
On Tue, 2009-11-10 at 14:16 -0700, Eran Hammer-Lahav wrote:
> My 2c:
> WRAP was developed out of necessity due to limitations in OAuth and
> product release schedule. Without going into too much detail about
> whether a whole new protocol was really necessary, the WRAP authors
> felt that it was, and that their timeline could not accommodate
> waiting for the OAUTH WG to accommodate their use cases in the new
> version of the spec. We now have a new and separate spec in the space.
> I have encouraged the authors to submit their spec as input for the WG
> and to collaborate to make the upcoming WG spec cover their use case.
> The goal would be to render the separate WRAP spec unnecessary. How
> they or others would choose to apply this to their implementation is
> beyond my control or (TBH) interest.
> Most of the innovative ideas in WRAP are around the delegation flow
> (and there are some good ideas in there). I plan to use some of that
> as the basis for the new delegation spec. On the authentication side,
> WRAP uses bearer token with no crypto which will be supported by the
> PLAIN flavor.
> As for how to manage community expectations, the OAuth brand, etc.: I
> was opposed to putting WRAP under the OAuth brand (the entire effort
> started as “Simple OAuth”). Others felt that pretending WRAP was an
> OAuth profile (it is not) and naming it as such would be less
> confusing or less damaging to the OAuth brand (if you call it the same
> thing, there is no competition). I didn’t care enough to (continue)
> that argument given my view that by the time WRAP will get the wide
> attention OAuth has, this WG will produce stable drafts of the new
> OAuth and will make this irrelevant.
> On 11/10/09 11:56 AM, "Paul C. Bryan" <em...@pbryan.net> wrote:
> I guess I must admit I'm a bit surprised that the general
> would be to merge with/profile WRAP as OAuth, as the deltas
> between the
> two protocols as defined seems quite substantial. Does this
> mean that
> for all intents and purposes I should consider the existing
> OAuth IETF
> drafts to date to be deprecated in favour of WRAP?
> On Tue, 2009-11-10 at 19:46 +0000, Dick Hardt wrote:
> > Good question. Given the positive reception WRAP received at
> IIW and
> > that capabilities in WRAP are expected to come out of the
> work in the
> > IETF OAuth WG, there was consensus from the OAuth community
> to include
> > WRAP as OAuth profiles.
> > -- Dick
> > On 2009-11-10, at 10:06 AM, "Paul C. Bryan"
> <em...@pbryan.net> wrote:
> > > Hi Dick:
> > >
> > > Given that WRAP is so different from OAuth (as I know it),
> other than
> > > the fact that OAuth could be used to negotiate the
> issuance of a WRAP
> > > refresh token, I'm curious why you chose to associate this
> > > OAuth by
> > > giving it an "OAuth" prefix. It seems to me that it would
> only create
> > > confusion in this space.
> > >
> > > Paul
> > >
> > > On Tue, 2009-11-10 at 17:52 +0000, Dick Hardt wrote:
> > >> At IIW last week, myself, Biran Eaton from Google and
> Allen Tom from
> > >> Yahoo! presented what is now called OAuth WRAP
> > >>
> > >> The specs and discussion specific to those documents is
> > >>
> > >> http://groups.google.com/group/oauth-wrap-wg
> > >>
> > >> We plan to submit the document as an I-D next week when
> > >> submission
> > >> is open again, and for further work to occur in the IETF
> OAuth WG.
> > >>
> > >> -- Dick
> > >> _______________________________________________
> > >> OAuth mailing list
> > >> OA...@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/oauth
> > >
> > > _______________________________________________
> > > OAuth mailing list
> > > OA...@ietf.org
> > > https://www.ietf.org/mailman/listinfo/oauth
> > >
It's not clear to me that this distinction would force someone to define
or label a new protocol. For instance in XMPP the protocol requires
support for TLS in *implementations*, but leaves the use of TLS by any
one *deployment* up to local service policy.
> This is an important distinction, though I assume it applies only to the
> profile(s) supplied as part of WRAP and not to extension profile(s) that
> may be created. E.g., one could create a fourth profile which did not
> require HTTPs -- it just would not be as interoperable as the others,
> and servers and clients are not required to support it, but it would be
> otherwise compatible with WRAP if I understand correctly.)
> "The Access Token in OAuth WRAP is opaque to
> the Client.
Isn't the token always opaque to the client? What semantic information
should we expect a client to clean from an access token?
> The Client does not need to perform
> any cryptography except for calling HTTPS."
A security review would tell us if that assumption is warranted. And,
again, this seems to be more of a deployment choice (the client and
server require SSL/TLS and therefore feel safe in using PLAINTEXT) than
a protocol change.
> This is also important, but what is the difference between WRAP and
> OAuth 1.0A PLAINTEXT mode? They seem to be pretty much identical to me,
> if there is a difference it should be called out.
> "The Access Token in OAuth WRAP can contain
> authorization information, or claims, enabling the
> Protected Resource to determine the Client's
> authorization without querying any other resource."
> I don't understand this distinction; this sounds exactly like the OAuth
> 1.0a token. What am I missing?
Yes, this sounds very similar.
I feel that this is a great initiative but may dilute the efforts of
the core oAuth protocol if kept as a separate spec and in general
having the two parallel specs may dillute the influence of each one of
Thoughts? The last thing we would want to do is confuse adopters
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.
You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.