Subject: [OAUTH-WG] SAML Assertion Draft Items

From: Brian Campbell <[email-masked]>
Date: Thu, 7 Jul 2011 13:05:40 -0600

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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 7 Jul 2011 22:24:04 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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.
> 
> 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.

> 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/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