Subject: [OAUTH-WG] assertion, client_assertion_type and client_assertion

From: Marius Scurtescu <[email-masked]>
Date: Sun, 30 Jan 2011 14:30:14 -0800

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.

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.

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.

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.

While the above issue is minor, I think it would be useful if core
defined these parameters as extension points.

Marius

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 30 Jan 2011 15:58:04 -0700

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Mon, 31 Jan 2011 07:16:11 -0700

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 <[email-masked]> wrote:
>> Marius Scurtescu