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" <mark.mcgl...@ie.ibm.com> wrote:
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:
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 <cmortim...@salesforce.com>
wrote:
That sounds like a very accurate description to me.
-cmort
On 7/8/10 3:27 PM, "Brian Campbell" <bcampb...@pingidentity.com> wrote:
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
