Subject: [OAUTH-WG] assertion profile changes

From: Brian Eaton <[email-masked]>
Date: Wed, 7 Jul 2010 09:40:54 -0700

Hi folks -

What is the story with the evolution of the assertion profile?

As far as I can tell, it keeps changing for no good reason.  Everyone who
wants to implement the profile has the exact same requirements, and
agreed on how it should work a long time ago.

Here's the timeline:

- a bunch of people get together and do WRAP.  It contains a flow that
exchanges a signed assertion for a short-lived bearer token.

- WRAP becomes OAuth2.  Assertion profile is dropped.

- People protest.

- Assertion profile is added back.

- OAuth2 interim meeting: a bunch of people stand up and say they
either have implemented or are implementing the assertion profile.
(Note that this is a superset of the people who worked on WRAP.  More
organizations have come on board.)

- Everything is fine until draft 7 of the OAuth 2 spec is published.
Assertion profile has changed, security is screwed up.  People
protest.

- Draft 8 makes it even worse, adding new secrets with no visible purpose.

- Yaron notices, complains, is told that he should write new spec language.

- Yaron writes new language.

- Argument starts over whether this is really necessary.

This is beginning to seem brain dead.

Can we please put the assertion profile back the way it was
in WRAP and Draft 6 of the OAuth 2 spec?  This is a critical use case
for a bunch of companies, all of whom have already agreed on how it
should work, and most of whom already have working implementations.

It's fine with me if people have other use cases for assertions, and
need new protocol flows to support those use cases.  But that's a
terrible reason to screw up the existing use cases.

Cheers,
Brian

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 7 Jul 2010 10:52:11 -0700

Good catch Brian - client_id and client_secret now seem mandatory when reading draft 9.   When those were originally added to the flow, they were clearly marked as optional.   That is lost in the latest drafts.

We'd be happy with either optional or removed.   Mandatory doesn't work for us at all.

-cmort

On 7/7/10 9:40 AM, "Brian Eaton" <[email-masked]> wrote:

Hi folks -

Here's the timeline:

- People protest.

Cheers,
Brian
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Jul 2010 13:08:40 -0700

> What is the story with the evolution of the assertion profile?

It is pretty much the same as originally proposed. Any recent changes are an
oversight, not any intentional change. Since it was proposed, the only
change made (with full consensus) was to allow client authentication as an
optional request parameter, as well as allow a refresh token as an optional
response parameter.

> - Assertion profile is added back.

Wrong.

The WG drafts have always included the assertion profile. I was missing from
David's initial draft and was added by me not because of any such protest
but because I wanted the first draft to represent the full combination of
OAuth 1.0, WRAP, and the token scheme.

> organizations have come on board.)

This is out of context.

We had a discussion about moving flows out of the core specification. We
discussed each flow. There were some calls for moving the assertion flow
out, as well as the device flow and native applications flow. After a
productive (and pleasant) discussion, we decided that there are enough
active use cases to keep it in.

> Assertion profile has changed, security is screwed up.  People

I do not recall any such changes or protest. Draft -07 changed the prose and
some parameter names, but has not changed the core details of the protocol
or the assertion flow. The so called "protest" was a handful of people
asking to bring back the 'type' parameter (and some saying it was not
needed). The parameter was promptly re-introduced as 'grant_type'.

If you have specific issues with regard to "security is screwed up" please
raise them.

> - Draft 8 makes it even worse, adding new secrets with no visible purpose.

The changes in client authentication were explicitly discussed and requested
at the meeting, mostly by those who also promoted the assertion flow. I
agree that the fact that the current prose *requires* client authentication
(instead of keeping it optional as previously agreed) is a problem. But
that's a oversight - not high drama.

> - Argument starts over whether this is really necessary.

This is not how I understood it, but Yaron is free to correct me if I am
wrong. Yaron supported the new language in section 2 and wanted to *add* to
it the ability to authenticate the client using an assertion. This is
another assertion for client authentication, not as an access grant.

> This is beginning to seem brain dead.

The same way this timeline represents reality.

> should work, and most of whom already have working implementations.

It is. I will fix the client authentication issue - thanks for the feedback.
But from my understanding, people who care about the assertion flow already
implemented it and did not express the same views as you. If you want
additional changes, suggest them as feedback to -09. That's the current
process.

> terrible reason to screw up the existing use cases.

The assertion access grant is the built-in profile extensibility mechanism
in OAuth 2.0. This makes is a core part of the protocol. However, this does
not mean it needs to be (or is) different from what was originally proposed.

I don't know where all this alleged drama is coming from, but from where I
sit, this is exactly the same flow, with one mistake made in recent draft
making client authentication seem mandatory.

EHL

---

From: Brian Eaton <[email-masked]>
Date: Wed, 7 Jul 2010 14:02:32 -0700

> optional request parameter, as well as allow a refresh token as an optional

Can you point me to the e-mail threads that reached consensus on using
client authentication?

Can you point me to the e-mail threads that reached consensus on
returning a refresh token?

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Jul 2010 14:18:29 -0700

I don't have time to go dig through the list archive.

> Can you point me to the e-mail threads that reached consensus on using

This was requested a few months ago and was included in -05 as optional. I
did not see any feedback requesting to remove this.

> returning a refresh token?

I raised this a long time ago about making the token endpoint output
consistent across all request types. At the time, consensus was that there
was no reason not to allow it, but that in general is should not be done
(refresh token when using assertions).

The current language has a SHOULD NOT issue a refresh token. It is not a
MUST NOT because someone recently asked for the ability to issue a refresh
token when the client nature prevents it from retaining the original
assertion used.

If you have an objection to the SHOULD NOT (vs. MUST NOT), please raise it
the the group will discuss.

EHL

---

From: Justin Hart <[email-masked]>
Date: Wed, 7 Jul 2010 14:31:04 -0700

I'm currently finishing an extension spec for client-to-client access delegation based on the assertion profile.  I believe it will use the client secret and return a refresh token, because the assertion is meant to be temporary, at least in its current form.  If the assertions are moving in a different direction I will need to refactor to follow suit.  (btw, expect a url to my draft by the end of the week, I hope)
----
-- Justin Hart
-- [email-masked]

---

From: Brian Eaton <[email-masked]>
Date: Wed, 7 Jul 2010 14:42:30 -0700

> did not see any feedback requesting to remove this.

OK, here it is: http://www.ietf.org/mail-archive/web/oauth/current/msg02545.html

I see that I was +1 on client_id and client_secret, so long as they
were optional. =)

I'd like to withdraw that +1.  Optional input and output parameters
have made the specification very confusing.

If someone needs client_id and client_secret, great, they can explain
their use case and propose a profile to address it.  But the original
use case for the assertion flow has no use for client ids.

> (refresh token when using assertions).

Please review this thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg02188.html.

I am sure there are people out there who want to use refresh tokens
with SAML assertions.  Good for them.  But it's a different use case.
It should be moved to a different profile.

It is not a good idea to jam multiple use cases into a single protocol
flow with a bunch of optional inputs and outputs.

Instead different use cases should be separate profiles, with
mandatory inputs and mandatory outputs.

If there are going to be optional inputs and outputs, there should be
clear guidance as to when they are expected and when they are not.

Cheers,
Brian

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Jul 2010 14:52:57 -0700

I disagree with this approach. There are plenty of optional parameters in the spec.

The assertion access grant requires further profiling to be useful. This doesn't mean it needs another spec, but that when you use it, you need to document clearly what is expected. When you do that, spell out what you support and what not.

It is not clear what about allowing client authentication or refresh token breaks security. This is purely a deployment decision for each provider.

If you would like to request specific changes to draft -09, please list them and explain why you are requesting them.

EHL

On 7/7/10 2:42 PM, "Brian Eaton" <[email-masked]> wrote:

Cheers,
Brian

---

From: Brian Eaton <[email-masked]>
Date: Wed, 7 Jul 2010 15:01:21 -0700

> I disagree with this approach. There are plenty of optional parameters in

Yes.  I think most of them are a bad idea.

> The assertion access grant requires further profiling to be useful. This
> doesn’t mean it needs another spec, but that when you use it, you need to
> document clearly what is expected. When you do that, spell out what you
> support and what not.

It doesn't, actually.  Lots of people have existing SAML assertion
formats that they support, and they are going to use the SAML to
access token swap without any further spec writing.

> It is not clear what about allowing client authentication or refresh token
> breaks security. This is purely a deployment decision for each provider.

Please see this thread:
http://www.ietf.org/mail-archive/web/oauth/current/msg02218.html.

Note multiple voices of approval for dropping the refresh token.

Note that people who want the refresh token have *completely different
use cases*.

Steering multiple use cases into the same profile is how we made OAuth
1.0 complex, slow, and insecure.  Let's not make the same mistake with
OAuth 2.

> If you would like to request specific changes to draft –09, please list them
> and explain why you are requesting them.

I'd like to see the following changes:

1) Separate profiles for separate use cases.
   The spec started off this way, and recent drafts have made it
progressively more compressed.  Shorter is not a win.

2) Drop refresh token, client id, and client secret from the SAML flow.
    If someone needs them, that's OK, but put it in different profile
for a different use case.

Cheers,
Brian

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 7 Jul 2010 15:23:25 -0700

On 7/7/10 3:01 PM, "Brian Eaton" <[email-masked]> wrote:

> doesn't mean it needs another spec, but that when you use it, you need to

I'd probably agree with Eran on this one - additional spec isn't required, but in absence, additional doc almost certainly will be.

We are strongly against any mandatory client credentials, however, as long as client creds are optional, then it's up to the server or profile to define.   I'm not sure I get the objection, as it remains under your control.

Please see this thread:

Refresh tokens are already labeled as SHOULD NOT, which I find strong enough; if others want to do something crazy with the flow I consider it up to them.   We are are strongly against any SHOULD or MUST language on refresh tokens.

I don't really view the assertion flow in current form to be anything but a basis for futher profiling or docs.   In both these cases, it seems like the server maintains control.   I'm certain we can't expect interoperable clients using SAML without further profiling / doc / agreement.

-cmort

Cheers,
Brian

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 7 Jul 2010 16:51:22 -0700

This thread forced a great deal on internal discussion today, and we
actually do have some more immediate use-cases where we'll require
client_id with the assertion flow

I support leaving it as optional

-cmort

---

From: Brian Eaton <[email-masked]>
Date: Wed, 7 Jul 2010 18:04:05 -0700

> I support leaving it as optional

Can you describe the additional use cases?

And do they require refresh tokens as well?

I'm really worried about jamming multiple use cases into a single
profile, and then being surprised when:
a) that profile is suboptimal for all of the use cases
b) developers are hugely confused by it

Cheers,
Brian

---

From: Chuck Mortimore <[email-masked]>
Date: Wed, 7 Jul 2010 18:25:01 -0700

Use-case:   When establishing web federation with customers we allow
them to either use their salesforce username ( enforced to be globally
unique ) or a federationid ( enforced to be unique to that particular
customer/tenant ) as the subject of their SAML assertion.   Since our
SAML ACS is global for all customers, as is our OAuth token endpoint,
when federationid is being used we need an additional piece of data to
disabiguate the customer...essentially namespacing the federationid.
 On our ACS endpoint, we accept a parameter.  For this use-case on our
token endpoint we'll use client_id. The alternative us we use some
other proprietary parameter to identify what org the client belongs
to.

This is optional for us, and depends on an individual customer configuration.

We will not be issuing refresh tokens.   Clients will need to get/mint
a new one-time-use saml bearer assertion if they want a new access
token

I'm a believer that devs will have to reference other docs and specs
for the assertion flow.  Perhaps making this language stronger would
help?

-cmort

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 7 Jul 2010 18:56:45 -0700

BTW, I'm not opposed to writing more detailed profiles based on the generic framework provided by the two endpoints defined and theyr many optional components. I think the new format helps clarify the overall architecture and easier to implement a generic client for (given that all the parameters for each endpoint are listed in a single place).

If people think this can be useful, I'm happy to give it a try once -10 is out and declared stable.

EHL

Please see this thread:

Cheers,
Brian

---

From: Laurens Van Houtven <[email-masked]>
Date: Thu, 8 Jul 2010 10:51:36 +0200

Just pitching in as someone writing something that might want a
refresh token but *really* doesn't understand why he'd need them. They
make very little sense to me; why not just make the token that allows
you to access a protected resource last longer? Use case: we've got
protected resources that get updated regularly, and authorizations to
read from it are always long-term (generally indefinitely).

Not that my vote carries much weight, but I'm definitely in favor of
simply dropping refresh tokens.

cheers
Laurens

---

From: Kris Selden <[email-masked]>
Date: Thu, 8 Jul 2010 02:53:47 -0700

The refresh token is key to separating concerns of the protected resource from the auth server.

I think this is succinctly explained the original rationale (refresh token = refresh secret):
http://wiki.oauth.net/ScalableOAuth#Appendix

---

From: Laurens Van Houtven <[email-masked]>
Date: Thu, 8 Jul 2010 13:29:49 +0200

> http://wiki.oauth.net/ScalableOAuth#Appendix

That suggests security issues. If I use tokens that can be used to
access protected resources for extended periods of time, why can't I
just revoke the compromised tokens (possibly all of them) when a leak
is discovered? It seems somewhat convoluted to introduce a new system
and then just wait until a timeout happens (although that timeout may
be acceptably small)...

I do not understand how it separates concerns more than they were
already separated under OA1.0a. Under OA1.0a, if I understand
correctly, the auth server produces tokens, and the protected resource
consumes them. That feels like two separate concerns to me.

cheers
Laurens

---

From: Justin Richer <[email-masked]>
Date: Thu, 8 Jul 2010 11:21:30 -0400

Would it help if the client_ stuff were dropped from the example in the
assertion flow? I'm in favor of it being allowed, but if the general use
case is going to be without it then the example should reflect that and
cut down on the confusion. 

 -- Justin

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 8 Jul 2010 08:53:44 -0700

Already is.

http://github.com/theRazorBlade/draft-ietf-oauth/raw/3e9a1e67807b7bbfe79ca4045a44b613ef45c990/draft-ietf-oauth-v2.txt

EHL

On 7/8/10 8:21 AM, "Justin Richer" <[email-masked]> wrote:

 -- Justin

---

From: Brian Eaton <[email-masked]>
Date: Thu, 8 Jul 2010 12:29:08 -0700

OK, I *think* I understand your use-case...  Just to be clear, even
after your internal discussions, you don't see a need for a client
secret in this flow?

Our SAML endpoints encode the tenant in the URL like so:

https://www.google.com/accounts/<tenant>/acs

But I'd have no problem with supporting per tenant urls like this:

https://www.google.com/accounts/acs?tenant=<tenant>

In fact, our approval endpoints already support that kind of
parameterization.  For example, see the hd= parameter in this
documentation: http://code.google.com/apis/accounts/docs/OAuth_ref.html.
 This is used by partners who need an OAuth token, and already have a
good idea of which domain a given user belongs to.  It lets us
optimize the login experience.

I'm a little confused by using client_id to identify something that
isn't an API client.  It seems like in your proposed flow you're
assuming that the client_id is closely connected to the user being
authenticated.  That's not actually true for most of our use cases.

What are your thoughts on adding an optional "tenant" parameter to
both the authorization URL and the SAML ACS URL?  The format of tenant
would be provider specific, but I see value in using consistent
parameter names.

Cheers,
Brian

---

From: Yaron Goland <[email-masked]>
Date: Thu, 8 Jul 2010 19:32:30 +0000

Here is what I think happened.

In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format arguments were used to allow clients to authenticate themselves to token endpoints in two legged OAuth scenarios.

In OAuth 2.0 two legged OAuth as a separate definition was removed and instead merged into three legged OAuth (something that I think is a feature). But in making this transition the original wrap_assertion and wrap_assertion_format arguments got turned into assertion_type and assertion.

But (and this part is tricky so please read carefully) assertion_type and assertion were part of the grant_type structure which was not used for AuthN (the way client_id/client_secret are) but rather for AuthZ (like refresh tokens).

Having assertion/assertion_type was still a very good improvement in the protocol since we have plenty of real world scenarios where we need to use assertions for AuthZ but the change left  a big hole - how do use an assertion for AuthN?

That's where the client_assertion/client_assertion_type come in.

So the whole confusion really seems to have come about because OAuth in doing a good thing (unifying 2 and 3 legged patterns) ended up moving assertions from AuthN to AuthZ, which was actually a new (and useful) feature but as a consequence created a hole that didn't exist with WRAP when dealing with AuthN.

So by putting in client_assertion/client_assertion_type and keeping assertion/assertion_type we get the best of all worlds. We can now use assertions for both AuthN and AuthZ.

	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Brian Eaton
> Sent: Wednesday, July 07, 2010 2:03 PM
> To: Eran Hammer-Lahav
> Cc: Hannes Tschofenig; OAuth WG
> Subject: Re: [OAUTH-WG] assertion profile changes
> 
> > It is pretty much the same as originally proposed. Any recent changes
> > are an oversight, not any intentional change. Since it was proposed,
> > the only change made (with full consensus) was to allow client
> > authentication as an optional request parameter, as well as allow a
> > refresh token as an optional response parameter.
> 
> Can you point me to the e-mail threads that reached consensus on returning
> a refresh token?

---

From: Brian Eaton <[email-masked]>
Date: Thu, 8 Jul 2010 12:43:09 -0700

And I am now seriously, seriously confused about your use case.

Why do you need refresh tokens?

Can you give more details?

On Thu, Jul 8, 2010 at 12:32 PM, Yaron Goland <[email-masked]> wrote:

> In OAuth WRAP section 5.2.3 the wrap_assertion and wrap_assertion_format
> arguments were used to allow clients to authenticate themselves to token
> endpoints in two legged OAuth scenarios.
>
> In OAuth 2.0 two legged OAuth as a separate definition was removed and
> instead merged into three legged OAuth (something that I think is a
> feature). But in making this transition the original wrap_assertion and
> wrap_assertion_format arguments got turned into assertion_type and
> assertion.
>
> But (and this part is tricky so please read carefully) assertion_type and
> assertion were part of the grant_type structure which was not used for AuthN
> (the way client_id/client_secret are) but rather for AuthZ (like refresh
> tokens).
>
> Having assertion/assertion_type was still a very good improvement in the
> protocol since we have plenty of real world scenarios where we need to use
> assertions for AuthZ but the change left  a big hole - how do use an
> assertion for AuthN?
>
> So the whole confusion really seems to have come about because OAuth in
> doing a good thing (unifying 2 and 3 legged patterns) ended up moving
> assertions from AuthN to AuthZ, which was actually a new (and useful)
> feature but as a consequence created a hole that didn't exist with WRAP when
> dealing with AuthN.
>
> So by putting in client_assertion/client_assertion_type and keeping
> assertion/assertion_type we get the best of all worlds. We can now use
> assertions for both AuthN and AuthZ.
>
>        Yaron
>

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 8 Jul 2010 13:29:13 -0700

On 7/8/10 12:32 PM, "Yaron Goland" <[email-masked]> wrote:

I'm not sure I agree with this.   I read the 09 spec as clearly being a 2-legged OAuth flow.   I actually read your suggested text as enabling assertions for 3 legged flows.

How is the current text 3 legged?

-cmort

        Yaron

---

From: Brian Campbell <[email-masked]>
Date: Thu, 8 Jul 2010 16:27:06 -0600

Maybe I'm the only one having a hard time following this thread but I
suspect I'm not alone.   I'm going to try and just summarize the
issues - mostly for my own edification but hopefully this may help
others too.  Please let me know if I'm off base.

The thread originally started with a discussion of the assertion grant
type as it's now called in -09 section 4.1.3 @
http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and
there seemed to be two points of contention specifically about it:

1) Should returning a refresh token be allowed?   Currently the text
in that section says, "The authorization server SHOULD NOT issue a
refresh token."   Some folks feel that is sufficient but some feel it
should be a MUST NOT.

2) Should client authentication be required/optional/forbidden when
requesting an access token via an assertion grant type.   The text in
-09 makes it sound like it might be mandatory (because of text in
http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4 maybe?).
No one thinks mandatory is a good idea.  Eran indicated that the
intent was for it to be optional and -10 would reflect that.   Some
people feel that client authentication in the assertion grant type is
necessary/confusing and should explicitly forbidden rather than just
optional.

More recently the thread has turned to a discussion of client
authentication and if/how the spec should allow for clients to
authenticate themselves to the token endpoint using means other than
the client_secret.  Section 2
http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves the
means of client authentication pretty open, it seems, but then only
provides normative guidance for "Basic Client Credentials" in section
2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1

I believe that Yaron is auguring for a something that might become a
section 2.2 called "Assertion Client Credentials."  But this is not
related to the assertion grant type (especially if client
authentication is forbidden from that grant type request).

How's my characterization of this?  If it's accurate, I think there's
value in realizing that there are two pretty distinct issues in
question here and I feel like some of the conversations around
"assertions" have been confused by mixing the two.  I'm not, at this
point, arguing the merits of anything - just first trying to make sure
we are arguing about the same things.

-Brian Campbell

---

From: Chuck Mortimore <[email-masked]>
Date: Thu, 8 Jul 2010 15:34:18 -0700

That sounds like a very accurate description to me.

-cmort

On 7/8/10 3:27 PM, "Brian Campbell" <[email-masked]> wrote:

-Brian Campbell

---

From: Brian Eaton <[email-masked]>
Date: Thu, 8 Jul 2010 15:49:21 -0700

Nice summary, thanks Brian!

I think there is a third issue as well, i.e. what the use case for client_id
actually is.

I think Chuck's use case has client_id used to disambiguate the purpose of
the SAML assertion.  We have a similar use case, both for SAML assertions
and three-legged OAuth approvals, but I don't think overloading client_id
for that is wise.

Cheers,
Brian

On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore
<[email-masked]>wrote:

> >> From: [email-masked] [mailto:[email-masked]<[email-masked]>]
> On Behalf
> >> Of Brian Eaton

---

From: Mark Mcgloin <[email-masked]>
Date: Fri, 9 Jul 2010 09:49:03 +0100

Agree, good summary Brian C

I still haven't seen the use case for refresh tokens with assertion flow!
We can control that server side but it is easier to just implement the spec
as is.

It seems insecure granting a refresh token with potentially longer life
than the assertion. Do people intent on using refresh tokens with
assertions intend to link the two?

Regards
Mark McGloin

On 08/07/2010 23:49 Brian Eaton wrote:

I think there is a third issue as well, i.e. what the use case for
client_id actually is.

Cheers,
Brian

On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore <[email-masked]>
wrote:
  That sounds like a very accurate description to me.

  -cmort

        Maybe I'm the only one having a hard time following this thread but
        I
        suspect I'm not alone.   I'm going to try and just summarize the
        issues - mostly for my own edification but hopefully this may help
        others too.  Please let me know if I'm off base.

        The thread originally started with a discussion of the assertion
        grant
        type as it's now called in -09 section 4.1.3 @
        http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4.1.3 and
        there seemed to be two points of contention specifically about it:

        1) Should returning a refresh token be allowed?   Currently the
        text
        in that section says, "The authorization server SHOULD NOT issue a
        refresh token."   Some folks feel that is sufficient but some feel
        it
        should be a MUST NOT.

        2) Should client authentication be required/optional/forbidden when
        requesting an access token via an assertion grant type.   The text
        in
        -09 makes it sound like it might be mandatory (because of text in
        http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-4
        maybe?).
        No one thinks mandatory is a good idea.  Eran indicated that the
        intent was for it to be optional and -10 would reflect that.   Some
        people feel that client authentication in the assertion grant type
        is
        necessary/confusing and should explicitly forbidden rather than
        just
        optional.

        More recently the thread has turned to a discussion of client
        authentication and if/how the spec should allow for clients to
        authenticate themselves to the token endpoint using means other
        than
        the client_secret.  Section 2
        http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2 leaves
        the
        means of client authentication pretty open, it seems, but then only
        provides normative guidance for "Basic Client Credentials" in
        section
        2.1 http://tools.ietf.org/html/draft-ietf-oauth-v2-09#section-2.1

        I believe that Yaron is auguring for a something that might become
        a
        section 2.2 called "Assertion Client Credentials."  But this is not
        related to the assertion grant type (especially if client
        authentication is forbidden from that grant type request).

        How's my characterization of this?  If it's accurate, I think
        there's
        value in realizing that there are two pretty distinct issues in
        question here and I feel like some of the conversations around
        "assertions" have been confused by mixing the two.  I'm not, at
        this
        point, arguing the merits of anything - just first trying to make
        sure
        we are arguing about the same things.

        -Brian Campbell

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 9 Jul 2010 10:23:37 -0700

On 7/8/10 3:49 PM, "Brian Eaton" <[email-masked]> wrote:

I think there is a third issue as well, i.e. what the use case for client_id actually is.

I think Chuck's use case has client_id used to disambiguate the purpose of the SAML assertion.  We have a similar use case, both for SAML assertions and three-legged OAuth approvals, but I don't think overloading client_id for that is wise.

I really wouldn't characterize my use-case as disambiguating the purpose.   I really need it to look up the "client" configuration.   In my particular use-case ( customers posting SAML assertions with subjects that are only unique when namespaced to a particular IDP ), the client is really defined as a SAML IDP, and I'd be looking up it's metadata based upon the client_id.   This seems appropriate to me.

-cmort

Cheers,
Brian

On Thu, Jul 8, 2010 at 3:34 PM, Chuck Mortimore <[email-masked]> wrote:
That sounds like a very accurate description to me.

-cmort

On 7/8/10 3:27 PM, "Brian Campbell" <[email-masked] <http://[email-masked]> > wrote:

-Brian Campbell

On Thu, Jul 8, 2010 at 1:32 PM, Yaron Goland <[email-masked] <http://[email-masked]> > wrote:
>> From: [email-masked] <http://[email-masked]>  [mailto:[email-masked]] On Behalf
>> Of Brian Eaton
>> On Wed, Jul 7, 2010 at 1:08 PM, Eran Hammer-Lahav
>> <[email-masked] <http://[email-masked]> > wrote:
>> [email-masked] <http://[email-masked]>
> [email-masked] <http://[email-masked]>
_______________________________________________
OAuth mailing list
[email-masked] <http://[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 9 Jul 2010 10:41:34 -0700

To directly address the 3 issues in Brian C's summary:

1) I haven't seen any strong use-cases for the issuing of refresh tokens either, but we do find the SHOULD NOT language to be strong enough.

2) We support client_id being optional, and will have need for it.    No support for mandatory, nor do we have any intent to use client_secret with this flow.

3) Yaron's suggestion of adding assertion as an authentication type does have some merit.   It basically would allow an alternate client authentication mechanism beyond the client_secret, allowing for a variety of strategies that would keep the secret off the wire.

One approach would be to:

 *   Add optional language to section 2 as Yaron has suggested.   Personally I would stick with name/value definitions of "assertion_format" and "assertion" parameters as defined in 4.1.3    These could be used as an alternative for client authentication in any request that normally used client_secret.    For instance, you could send a grant_type=authorization-code and include an assertion to identify the client, rather than the shared secret.
 *   Change the authorization grant_type to make client_id optional (already planned), and simply reference assertion & assertion_format from section 2 as mandatory.

This seems like it would meet the goals of the folks that want to do 2-legged oauth with assertions, by leaving the fundamentals of section 4.1.3 in place, as well as expand the capabilities for assertions to be used as authentication, which is what Yaron is asking for.

-cmort

On 7/9/10 1:49 AM, "Mark Mcgloin" <[email-masked]> wrote:

Regards
Mark McGloin

Cheers,
Brian

  -cmort

        -Brian Campbell