> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Brian Campbell > Sent: Thursday, July 07, 2011 12:06 PM > To: oauth > Subject: [OAUTH-WG] SAML Assertion Draft Items > > WG, > > Unfortunately I will not be at IETF#81 and will probably not be able to post a > new draft of draft-ietf-oauth-saml2-bearer prior to the I-D submission cutoff > date. In lieu of that, I'd like to make a few proposals and/or ask a few > questions regarding the next draft in hopes of fostering some productive > discussion. > > Item 1: Profiling of draft-ietf-oauth-assertions Assuming the WG continues to > support draft-ietf-oauth-assertions, the SAML draft should become a > profile/extension of it. For SAML as a grant type, that should be easy and > even shorten/simplify this draft. > > However, the SAML draft does not currently cover SAML for client > authentication and profiling draft-ietf-oauth-assertions would suggest that it > should. Is there any general consensus as to if SAML should be profiled as a > client authentication method? It is certainly feasible but might require > restructuring and retitling the draft.
Are there use cases pending such functionality today? It would be a shame to delay an otherwise useful draft when the functionality can be added later. > 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. > 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. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
