mailto:oauth-boun...@ietf.org
[mailto:oauth-boun...@ietf.org] *On Behalf Of *Phil Hunt
*Sent:* Wednesday, April 24, 2013 3:55 PM
*To:* John Bradley
*Cc:* oauth@ietf.org mailto:oauth@ietf.org WG
*Subject:* Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 -
token_endpoint_auth_method
Right
...@ietf.org] On Behalf Of
Phil Hunt
Sent: Wednesday, April 24, 2013 3:55 PM
To: John Bradley
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 -
token_endpoint_auth_method
Right and if the client wants a method not supported then what?
Why can't
John, I don't think that anybody's actually suggesting that we add
server discovery in here. :) But since the server does echo back the
configuration in its response, the client is discovering a few things at
run time about what it can and can't do with a particular server. It's
entirely
I am not sure what to think about this.
1. I don't want this spec to be incomplete because there is another external
spec published for a specific purpose.
2. In general i would like to avoid negotiations. It seems to me that any
developer making a client for a mutli-site deployed service
On 04/25/2013 12:23 PM, Phil Hunt wrote:
I am not sure what to think about this.
1. I don't want this spec to be incomplete because there is another
external spec published for a specific purpose.
If we needed a registry we could define it in this spec. If we chose a
non-registry method
For parameters to token_endpoint_auth_method, the spec has defined
client_secret_jwt and private_key_jwt. Shouldn't there be similar options
of SAML?
Shouldn't there be an extension point for other methods?
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
Yes there should be corresponding client_secret_SAML and private_key_SAML.
Those parameters were taken from Connect which is more JWT focused so I didn't
put in the SAML options for token endpoint authentication, though they would be
valid.
There is probably some profiling that needs to be
Seems reasonable to me, can you suggest language to add in the
capability? Would it require an IANA registry? Right now there isn't any
other place that enumerates the various methods that a client can use to
access the token endpoint.
-- Justin
On 04/24/2013 04:17 PM, Phil Hunt wrote:
For
Hmmm… what was the objective or use case for having the client being able to
choose in the first place?
It seems to me that the AS will make a decision based on many factors. As you
say, there isn't any other place that enumerates the various [authn] methods a
client can use to access the
In Connect the AS may support a number of token endpoint authentication
methods. The reason to allow a client to register using a particular one is
to prevent downgrade attacks.
If the client wants to always use an asymmetric signature you don't want to
allow attackers to use weaker methods
Right and if the client wants a method not supported then what?
Why can't the client offer up a list of methods it is able to support, say in
order of preference?
The text appears to indicate only one value may be passed.
Given the way it is written. It seems better to just have the server say
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 -
token_endpoint_auth_method
Right and if the client wants a method not supported then what?
Why can't the client offer up a list of methods it is able to support, say in
order of preference?
The text
In Connect there is a AS discovery before registration.
The general pattern is the RP discovers the capabilities of the AS
authentication methods and algorithms supported by the AS.
The client then picks the best options for it and registers them.
It would in theory work of the client
.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Phil Hunt
Sent: Wednesday, April 24, 2013 3:55 PM
To: John Bradley
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09
14 matches
Mail list logo
