Re: [OAUTH-WG] Contents of OAuth digest

2013-04-24 Thread dorismark tyne
Please explain what oauth is all about. Thanks dmtyne - Original Message - From: oauth-requ...@ietf.org To: oauth@ietf.org Sent: Friday, April 19, 2013 3:00 PM Subject: OAuth Digest, Vol 54, Issue 43 If you have received

[OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

2013-04-24 Thread Phil Hunt
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 ___

Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

2013-04-24 Thread John Bradley
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 don

Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

2013-04-24 Thread Justin Richer
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 p

Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

2013-04-24 Thread Phil Hunt
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 token

Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

2013-04-24 Thread John Bradley
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 l

Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

2013-04-24 Thread Phil Hunt
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

Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

2013-04-24 Thread Mike Jones
What you're missing is the part of the OpenID Connect flow where the client first discovers the capabilities that the Server advertises. In this case, it uses this discovery parameter: token_endpoint_auth_signing_alg_values_supported OPTIONAL. JSON array containing a list of the JWS signing alg

Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

2013-04-24 Thread John Bradley
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 knowi

Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

2013-04-24 Thread Phil Hunt
Fair enough, but that doesn't make sense in this broader forum where discovery isn't assumed. Phil On 2013-04-24, at 16:17, Mike Jones wrote: > What you’re missing is the part of the OpenID Connect flow where the client > first discovers the capabilities that the Server advertises. In thi