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. 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 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. 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. Item 3: Processing rules An out of band request came from folks at a large company to change/relax the validation rules in order to allow for interoperability with existing software products. Which seems very reasonable. The change would basically amount to relaxing the MUST on the <SubjectConfirmationData> element to a SHOULD (or maybe loser even) while adding a requirement for a NotOnOrAfter attribute on the <Conditions> element (possibly conditionally based on the existence of it, or not, on the <SubjectConfirmationData>). It's a little hard to explain but hopefully that conveys the idea. It seems like a change that should be made but I wanted to get some feedback from a wider group before doing it. I realize the assertion stuff is secondary to the core protocol for most of you but I that you, if you've read this far, and I welcome and appreciate any thoughts/feedback on these issues/questions. Thanks, Brian _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
