I'm happy to make that change. But is it really necessary? The assertion parameter in draft-ietf-oauth-saml2-bearer is defined in the context of using the "http://oauth.net/grant_type/assertion/saml/2.0/bearer"; grant type. Couldn't it be argued that other URI grant types could make use of it without issue or conflict? Does this suggest that the registry isn't granular enough? It seems the definition of the assertion parameter in the context of a new grant type should probably prohibit its use in other extension mechanisms that might be used along side the grant but not in other grant definitions (AFAIK, there's no way to present two grants at the same time).
On Sun, Jan 30, 2011 at 3:58 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: >> -----Original Message----- >> Marius Scurtescu >> >> The assertion parameter was in core, but it was removed and now it is >> defined by SAML 2.0 Bearer Assertion Grant Type Profile. What will the next >> assertion extension do, let's say JWT? It can either re-define the assertion >> parameter or it can reference SAML 2.0 Bearer. Does re-defining imply >> registration as well? How would that work? Having JWT depend on SAML >> does not make much sense. > > It makes no sense to define this parameter in the authorization specification > because assertions are no longer discussed. It would be a very odd and out of > context definition. The appropriate solution here is for the SAML > specification to change its definition of the assertion parameter to be more > generally applicable. For example: > > assertion > REQUIRED. The assertion used to obtain an access token. The value of > the > assertion parameter MUST contain a single assertion. When used with > the > http://oauth.net/grant_type/assertion/saml/2.0/bearer"; grant type, > the > assertion MUST be a SAML 2.0 Assertion. The SAML 2.0 Assertion XML > data > MUST be encoded using base64url, where the encoding adheres to the > definition in Section 5 of RFC4648 [RFC4648] and where the > padding bits are set to zero. To avoid the need for > subsequent encoding steps (by "application/ > x-www-form-urlencoded" [W3C.REC-html401-19991224], for > example), the base64url encoded data SHOULD NOT be line wrapped > and pad characters ("=") SHOULD NOT be included. > > This way, other specifications can simply use this parameter as-is without > any additional registrations or updates. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
