Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12

[Bill Mills <[e-mail]>]

I've included the language change for scope.


On Authz-ID we ended up with some kind of fuzzy language there and we knew it.  The problem being that it will depend on the specific implementation.  It's possible to do OAuth 1.0a without any useful client authentication for example.  I'm not in love with the current language, but I can't see a better way without forcing some set of reasonable implementations into non-compliance.

 
-bill



--------------------------------
William J. Mills
"Paranoid" Yahoo!





On Wednesday, December 18, 2013 11:10 AM, Matt Miller (mamille2) <[e-mail]> wrote:
 

On Dec 18, 2013, at 11:24 AM, Bill Mills <[e-mail]> wrote:

> 
> We went around a number of times on the SASL identities.  The problem I see is that the assertion of authz-id if it's specified separately in protocol just has to be matched/confirmed by the token anyway so the value should just be derived from that.
> 

I still think you're still conflating authn-id and authz-id here.

An example: let's say we have an XMPP service, where a session is long-lived and have a strong identity (effectively, the sender address cannot be anything other than what the user logged in with).  Our resource owner has multiple identities on this service ("[e-mail]", "[e-mail]", "[e-mail]") but one set of credentials on the authorization server.

In this case, what should the XMPP service use for the identity?

For most other SASL mechanisms, this is where authz-id is used.  It still absolutely requires the resource server to confirm the authz-id is appropriate for the given credentials (token).  If there were only one possible identity, then the client shouldn't even specify an authz-id (IMO).  But where there are multiple possible identities, the user might want to pick one other than the default.

Now, it could very well be that the above is not something that ought to be supported for SASL-OAuth.  It could be that the resource owner needs to choose the specific identifier to use as part of the OAuth authorization flow before the token is even granted.  If this is the most desired case, then the mechanisms need to specifically state that they do not transfer authorization identity strings.

> 
> Not sure why the MAC token draft number is wrong.  I'm using the xml2rfc format and referring to <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-oauth-v2-http-mac.xml' ?> so I'm not sure what to fix.
> 

Hrm.  Maybe there is an overly aggressive caching proxy between you and xml.resource.org, or an overly aggressive local cache?

I would suggest using "https://", but it looks like the cert isn't valid for xml.resource.org!

/me notes to follow up on that...

> On scopes, I'm not liking your changes but see the problem.  The current text is:
> 
> "An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a space separated list. Use of a space separated list is NOT RECOMMENDED."
> 
> I propose:
> 
> "An OAuth scope which is valid to access the service. This may be empty which implies that unscoped tokens are required, or a scope value.  If a scope is specified then a single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED."
>  

That works for me, and I think that's what most deployments will want to do.


- m&m

Matt Miller < [e-mail] >
Cisco Systems, Inc.


> -bill
> 
> P.S. Nits...  "erk" is actually a sound made when you drop something on your foot, "irk" is indicative of the reaction to excessive pedantry. :)
> 

I said erk out loud when i saw it, does that count (-: