Re: [OAUTH-WG] oauth assertions plan

[Brian Campbell <[e-mail]>]

I do believe some face to face discussion amongst a smallerish group might
be valuable on this. I'll be in Orlando and plan on contributing to that as
much as I can. Thanks for organizing the lunch discussion Stephen.

I do feel that this conversation has strayed a bit and I'd like to clear up
one important misconception. The three assertion documents do not define an
access token type at all. The questions and concerns around bearer tokens
and MAC tokens and other token types may well be very legitimate but are
completely orthogonal to the scope and intent of the assertion documents.
The assertions drafts define how to trade an assertion for a an access
token at the token endpoint via the extension grant type mechanism provided
by RFC 6749. The assertions drafts also define an alternative means of
client authentication but its scope is very limited and only applies to a
client authenticating to the AS's token endpoint. I believe the documents
are pretty clear on what they seek to accomplish (and what they do not) but
this is definitely not the first time this has come up and that likely
points to the need for some more clarification in docs themselves.

It seems to me that much of the recent discussion here is largely unrelated
to that actual intent and scope of the documents in question. It may well
be valuable discussion but, even if we can find some common ground on it,
these assertion drafts probably aren't the right place to address these
issues.


On Mon, Feb 18, 2013 at 12:09 PM, Barry Leiba <[e-mail]>wrote:

> "Dynamically declaring," in what sense?  Where are those mechanisms
>> documented?****
>>
>> ** **
>>
>> Many of them are documented in draft-ietf-oauth-dyn-reg.****
>>
>> ** **
>>
>> One profile (an outer doll J) that enables fully interoperable
>> implementations is documented in draft-hardjono-oauth-umacore.
>>
>> ...
>
>>  Another related profile that enables fully interoperable
>> implementations is documented in
>> http://openid.net/specs/openid-connect-messages-1_0.html.
>>
>>
> It's possible, then, that this isn't an issue of major changes needed in
> this document, but one of document ordering.  It's possible (I'm still not
> sure, but maybe) that if some of these other documents came out before or
> at the same time as this one, they would all fit together and all would be
> clear.
>
> So maybe that's one way through this.
>
> In the end, all I'm saying is that if I hear that everyone is using oauth
> to peel bananas, and I want put my banana-peeling application on the market
> by adding oauth to it, I need to be able to read a set of specs that say
> how to do that, and that's all.  And if I do that, my application will work
> when it's slotted into any oauth-based banana-peeling system.
>
> Barry
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>