Hey Marius, It is critical for us to discuss the client assertion credentials separately from the assertion authorization grant. The two have nothing to do with one another.
EHL > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Marius Scurtescu > Sent: Sunday, January 30, 2011 2:30 PM > To: OAuth WG > Subject: [OAUTH-WG] assertion, client_assertion_type and client_assertion > > I would like to bring up one more argument to keep the assertion, > client_assertion_type and client_assertion parameters in core. > > If I understood correctly, the main argument to remove them from core was > that they are underspecified and extensions are needed anyhow before > they are useful. This is true for the client assertion credentials. The assertion parameter was moved because was previously defined, it was a required parameter when using any extension grant type. This was incorrect because not all extension grant types are assertion-based. Assertions are no longer directly discussed. > First of all, this is not true for client_assertion_type and > client_assertion. A > client can acquire assertions from an IdP that works intimately with the > client. > In this case the client knows how to get a client assertion and then how to > present it to the Authorization Server, but it really does not need to know > anything more. The IdP and the Authorization Server do need to agree on > format and keys, but not the client. This IdP entity does not exists in the specification. It's a new role. Because 99% of the work involved in using such a client assertion is determined elsewhere, the value of defining the two parameters (and nothing else) is minimal, but the confusion and complexity it brings are non-trivial. Just consider writing a useful security consideration section for this alternative flow. My main issue is the lack of specificity with regard to the client identifier and how it maps to the assertion. Since no assertion format is defined, it is impossible to define the means for the client to provide its client identifier within the assertion. There are many ways to solve this, and I expect to see this address in a new draft. Note that I am not objecting to including such functionality, only the currently underspecified language. This is why I have been asking repeatedly for someone to submit a complete text (I posted the criteria for what will make it complete earlier) for WG consideration. This text may be integrated back into the specification before publication. But depends completely on a new text winning consensus. > I agree that this is a less used use case, and that currently there are no > implementations to point at (as far as I know), but there is another reason to > keep these parameters in core. This other reason has nothing to do with the client assertion credentials... > 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. > While the above issue is minor, I think it would be useful if core defined > these parameters as extension points. > > Marius > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
