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 <[email protected]>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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
