On 7/7/10 9:40 AM, "Brian Eaton" <bea...@google.com> wrote:
> Hi folks -
>
> What is the story with the evolution of the assertion profile?
It is pretty much the same as originally proposed. Any recent changes are an
oversight, not any intentional change. Since it was proposed, the only
change made (with full consensus) was to allow client authentication as an
optional request parameter, as well as allow a refresh token as an optional
response parameter.
> As far as I can tell, it keeps changing for no good reason. Everyone who
> wants to implement the profile has the exact same requirements, and
> agreed on how it should work a long time ago.
>
> Here's the timeline:
>
> - a bunch of people get together and do WRAP. It contains a flow that
> exchanges a signed assertion for a short-lived bearer token.
>
> - WRAP becomes OAuth2. Assertion profile is dropped.
>
> - People protest.
>
> - Assertion profile is added back.
Wrong.
The WG drafts have always included the assertion profile. I was missing from
David's initial draft and was added by me not because of any such protest
but because I wanted the first draft to represent the full combination of
OAuth 1.0, WRAP, and the token scheme.
> - OAuth2 interim meeting: a bunch of people stand up and say they
> either have implemented or are implementing the assertion profile.
> (Note that this is a superset of the people who worked on WRAP. More
> organizations have come on board.)
This is out of context.
We had a discussion about moving flows out of the core specification. We
discussed each flow. There were some calls for moving the assertion flow
out, as well as the device flow and native applications flow. After a
productive (and pleasant) discussion, we decided that there are enough
active use cases to keep it in.
> - Everything is fine until draft 7 of the OAuth 2 spec is published.
> Assertion profile has changed, security is screwed up. People
> protest.
I do not recall any such changes or protest. Draft -07 changed the prose and
some parameter names, but has not changed the core details of the protocol
or the assertion flow. The so called "protest" was a handful of people
asking to bring back the 'type' parameter (and some saying it was not
needed). The parameter was promptly re-introduced as 'grant_type'.
If you have specific issues with regard to "security is screwed up" please
raise them.
> - Draft 8 makes it even worse, adding new secrets with no visible purpose.
The changes in client authentication were explicitly discussed and requested
at the meeting, mostly by those who also promoted the assertion flow. I
agree that the fact that the current prose *requires* client authentication
(instead of keeping it optional as previously agreed) is a problem. But
that's a oversight - not high drama.
> - Yaron notices, complains, is told that he should write new spec language.
>
> - Yaron writes new language.
>
> - Argument starts over whether this is really necessary.
This is not how I understood it, but Yaron is free to correct me if I am
wrong. Yaron supported the new language in section 2 and wanted to *add* to
it the ability to authenticate the client using an assertion. This is
another assertion for client authentication, not as an access grant.
> This is beginning to seem brain dead.
The same way this timeline represents reality.
> Can we please put the assertion profile back the way it was
> in WRAP and Draft 6 of the OAuth 2 spec? This is a critical use case
> for a bunch of companies, all of whom have already agreed on how it
> should work, and most of whom already have working implementations.
It is. I will fix the client authentication issue - thanks for the feedback.
But from my understanding, people who care about the assertion flow already
implemented it and did not express the same views as you. If you want
additional changes, suggest them as feedback to -09. That's the current
process.
> It's fine with me if people have other use cases for assertions, and
> need new protocol flows to support those use cases. But that's a
> terrible reason to screw up the existing use cases.
The assertion access grant is the built-in profile extensibility mechanism
in OAuth 2.0. This makes is a core part of the protocol. However, this does
not mean it needs to be (or is) different from what was originally proposed.
I don't know where all this alleged drama is coming from, but from where I
sit, this is exactly the same flow, with one mistake made in recent draft
making client authentication seem mandatory.
EHL
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
