Subject: [OAUTH-WG] conf call follow up from today

From: William Mills <[email-masked]>
Date: Mon, 4 Feb 2013 12:22:11 -0800 (PST)

1)  I think that we need to focus on specific solutions, as I said on the call, and solve the OAuth 1.0a/MAC use case.  There's significant installed base of OAuth 1.0a and we need a path for those installations into OAuth 2.0.  I may well pursue MAC in the interim to do this, but a full HOK solution woul work too.

2)  I think the discussion we were having about "which authenticator to use" falls squarely into the endpoint discovery discussion and we should put that energy into endpoint discovery as distinct from HOK.

3)  We haven't talked yet about how a client will be able to specify a token type if it wants a specific one.  OAuth 2 core will need to be extended to support this.

4)  We should leave the key distribution/discovery mechanism either out of scope or define it explicitly per HOK token type profile.  This will have to work with the extensions for #3 above.

5)  I want to avoid the problem in OAuth 1.0a of having to support and accept every possible signing mode.  Being force to accept PLAINTEXT sucks.  We need a way for the discovery endpoint to mandate a specific set of allowed signature methods.

Regards,

-bill

---

From: Prateek Mishra <[email-masked]>
Date: Mon, 04 Feb 2013 16:28:17 -0500

Bill -

How does OAuth 1.0a deal with the problem of HTTP URL and header 
mutability? Header order may get re-arranged and URLs modified in 
transit from client to server. As a result, the signature/HMAC
might not validate at the final destination.

Isn't that a foundational problem with the OAuth 1.0a model? I thought 
that was one of the concerns expressed at the meeting today.

- prateek

> 1)  I think that we need to focus on specific solutions, as I said on 
> the call, and solve the OAuth 1.0a/MAC use case.  There's significant 
> installed base of OAuth 1.0a and we need a path for those 
> installations into OAuth 2.0.  I may well pursue MAC in the interim to 
> do this, but a full HOK solution woul work too.
>
> 2)  I think the discussion we were having about "which authenticator 
> to use" falls squarely into the endpoint discovery discussion and we 
> should put that energy into endpoint discovery as distinct from HOK.
>
> 3)  We haven't talked yet about how a client will be able to specify a 
> token type if it wants a specific one.  OAuth 2 core will need to be 
> extended to support this.
>
> 4)  We should leave the key distribution/discovery mechanism either 
> out of scope or define it explicitly per HOK token type profile.  This 
> will have to work with the extensions for #3 above.
>
> 5)  I want to avoid the problem in OAuth 1.0a of having to support and 
> accept every possible signing mode.  Being force to accept PLAINTEXT 
> sucks.  We need a way for the discovery endpoint to mandate a specific 
> set of allowed signature methods.
>
> Regards,
>
> -bill
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Mon, 4 Feb 2013 13:33:27 -0800 (PST)

OAuth 1.0a solves ordering problems there but not additional data being added to the specific headers.  It specifically requires the library to break apart, sort, and reassemble in a alphabetical order by name the query string parameters and oauth_* parameters.  One of the less popular things about it. 

________________________________
 From: Prateek Mishra <[email-masked]>
To: [email-masked]; William Mills <[email-masked]> 
Sent: Monday, February 4, 2013 1:28 PM
Subject: Re: [OAUTH-WG] conf call follow up from  today

Bill - 

Isn't that a foundational problem with the OAuth 1.0a model? I
    thought that was one of the concerns expressed at the meeting today.

- prateek

>5)  I want to avoid the problem in OAuth 1.0a of having to support and accept every possible signing mode.  Being force to accept PLAINTEXT sucks.  We need a way for the discovery endpoint to mandat…
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 4 Feb 2013 21:37:06 +0000

What if we define a means to request OAuth1 style tokens from an OAuth2 auth/token endpoint, but defer to OAuth1 for methods of how to use the token at protected resources?

 -- Justin

On Feb 4, 2013, at 3:22 PM, William Mills <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

-bill

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Sergey Beryozkin <[email-masked]>
Date: Mon, 04 Feb 2013 21:42:08 +0000

On 04/02/13 20:22, William Mills wrote:
> 1) I think that we need to focus on specific solutions, as I said on the
> call, and solve the OAuth 1.0a/MAC use case. There's significant
> installed base of OAuth 1.0a and we need a path for those installations
> into OAuth 2.0.
+1.

> I may well pursue MAC in the interim to do this,

I can help with some testing if/when needed...

Sergey

> but a
> full HOK solution woul work too.
>
> 2) I think the discussion we were having about "which authenticator to
> use" falls squarely into the endpoint discovery discussion and we should
> put that energy into endpoint discovery as distinct from HOK.
>
> 4) We should leave the key distribution/discovery mechanism either out
> of scope or define it explicitly per HOK token type profile. This will
> have to work with the extensions for #3 above.
>

---

From: William Mills <[email-masked]>
Date: Mon, 4 Feb 2013 14:29:56 -0800 (PST)

We can do that too, and I rather like it.  I thought there was a big "don't cross the beams" warning somewhere though.

-bill

________________________________
 From: "Richer, Justin P." <[email-masked]>
To: William Mills <[email-masked]> 
Cc: O Auth WG <[email-masked]> 
Sent: Monday, February 4, 2013 1:37 PM
Subject: Re: [OAUTH-WG] conf call follow up from  today

 -- Justin

On Feb 4, 2013, at 3:22 PM, William Mills <[email-masked]> wrote: