Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)]

[Eran Hammer-Lahav <[e-mail]>]

> -----Original Message-----
> From: Brian Campbell [mailto:[e-mail]]
> Sent: Saturday, July 09, 2011 6:15 AM
> To: Eran Hammer-Lahav
> Cc: oauth
> Subject: Re: [OAUTH-WG] SAML Assertion Draft Items [Item 2: URI(s)]
> 
> 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-mail]> 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?

2648 is pretty limited in what it offers for the urn:ietf namespace. I'll post something to the app area list.

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

My experience is that people at the IETF have an allergic reaction to OASIS and while SAML is well-established, I would be surprised if you get far with using an OASIS namespace. Also, OASIS should be the only entity controlling the use of their identifiers and in theory, might want to use it with OAuth in a different way.

EHL