Discussion on the other item, the grant_type URI, inline below. This whole thing seems like it shouldn't be an issue at all as there's no functionality involved. But I've been hung up on it for a while and the spec needs some URI. I could *really* use the advice of the AD and/or Chairs on this. Or anyone with more experience with defining and using URIs/URNs.
Thanks. On Thu, Jul 7, 2011 at 11:24 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > >> Item 2: URI(s) >> The value for grant_type is currently defined as >> http://oauth.net/grant_type/saml/2.0/bearer but there have been some >> questions raised about the stability and appropriateness of the URL. > > I'm not a fan. > >> I really did read RFCs 2648 & 3553, as was suggested at the last F2F meeting, >> but it's not clear to me how to register an IETF URI and/or if those RFCs are >> fully appropriate for this. If someone could explain it to me in terms my >> preschooler could understand, maybe I could jump though the proper hoops >> to get the URI to be something like urn:ietf:something:something. > > Asking on the URN list usually helps. I can try that. I'm thinking it'd be something like urn:ietf:wg:oauth:2.0:grant_type:saml:2.0:bearer which is largely based on seeing the use of urn:ietf:wg:oauth:2.0:oob - was there an actual registration done for that? Or did it just start getting used? Is doing that okay? > >> Otherwise, I can continue to use >> http://oauth.net/grant_type/saml/2.0/bearer and, assuming the draft >> should also cover client authentication, also define >> http://oauth.net/client_assertion_type/saml/2.0/bearer. The JWT version >> could then follow a similar pattern. Or perhaps we could use the URI, >> urn:oasis:names:tc:SAML:2.0:cm:bearer which is defined in section 3.3 of >> saml-profiles-2.0-os as URI that identifies the bearer subject confirmation >> method. It seems like that might be close enough to work out without >> violating anything serious. And it could be used for both grant_type and >> client_assertion_type, which is nice. > > Don't use an OASIS URN. That's asking for trouble. Is it really? Because it's conceptually inappropriate? Or because of some supposed (or real) rift between standards bodies? I mean, this whole draft is about profiling SAML assertions (an OASIS spec) for use with OAuth (soon an IETF spec). Would using a URN too be so terrible? You'd previously suggested (or asked why I didn't use) urn:oasis:names:tc:SAML:2.0:assertion which is the XML NS for the OASIS SAML assertion schema. Would that somehow be different? That is still an option too, I think. I hadn't used it because I wanted to differentiate the means of confirming/validating the assertion - as a bearer token - while leavening room for holder of key or other methods in the future. But using that NS wouldn't necessary preclude it. I was also looking for an identifier that would enable easy web searching and urn:oasis:names:tc:SAML:2.0:assertion wouldn't really do that. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
