Re: [kitten] Updating OAuth SASL

Hi Bill, 

you are right that there are various aspects to consider. 

The first one is that there is a need to map the resource owner identifier from the OAuth exchange to the SASL/GSS-API used concepts. The need to describe such a mapping is created by the layering introduced. The text I distributed below tries to address that part (since it is not described elsewhere in the document). 

Then, there is a question of how the resource owner identifier is actually presented to the user (as part of the user interface). The problem is that there is no description in any of the OAuth documents about the syntax of the resource owner identifer. The only (not yet finished document) is the JWT that describes in which JSON field to put the string. It does, however, leave the syntax of the string undefined (intentionally). 

This obviously makes it a bit difficult to describe in the SASL OAuth document how such identifier canonicalization would look like. 

Ciao
Hannes

On Nov 23, 2012, at 2:17 AM, William Mills wrote:

> Nowhere in OAuth do we talk about normalizing or canonicalizing names IIRC, so there's at least one way this won't work.   I know what problem I was trying to solve with that language, I don't see how this language solves the problem.  Perhaps it doesn't need solving, I could believe that.  I think we need to define a way for the server to get (or derive by DB lookup for example) the identity out of the token, and we should also define how a server might get the client identity.  Since nothing in the token is defined as usable for display the current text also addresses that by adding it as a requirement.
> 
> How does the proposed language solve these things?
> 
> -bill
> 
> 
> From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
> To: William Mills <wmills@yahoo-inc.com>; Alexey Melnikov <alexey.melnikov@isode.com> 
> Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>; kitten@ietf.org 
> Sent: Thursday, November 22, 2012 6:38 AM
> Subject: Re: [kitten] Updating OAuth SASL
> 
> Hi Bill, Hi Alexey, 
> 
> I am wondering whether we couldn't just re-use the text we have in the SASL OpenID specification. 
> Here is the relevant text from Section 4.1 of RFC 6616:
> 
> ----
> 
> 4.1.  GSS-API Principal Name Types for OpenID
> 
>   OpenID supports standard generic name syntaxes for acceptors such as
>   GSS_C_NT_HOSTBASED_SERVICE (see Section 4.1 of [RFC2743]).
> 
>   OpenID supports only a single name type for initiators:
>   GSS_C_NT_USER_NAME.  GSS_C_NT_USER_NAME is the default name type for
>   OpenID.
> 
>   OpenID name normalization is covered by the OpenID specification; see
>   Section 7.2 of [OpenID].
> 
>   The query, display, and exported name syntaxes for OpenID principal
>   names are all the same.  There are no OpenID-specific name syntaxes
>   -- applications should use generic GSS-API name types such as
>   GSS_C_NT_USER_NAME and GSS_C_NT_HOSTBASED_SERVICE (see 
>   Section 4 of [RFC2743]).  The exported name token does, of course, conform to
>   Section 3.2 of [RFC2743], but the "NAME" part of the token should be
>   treated as a potential input string to the OpenID name normalization
>   rules.  For example, the OpenID Identifier "https://openid.example/"
>   will have a GSS_C_NT_USER_NAME value of "https://openid.example/".
> 
>   GSS-API name attributes may be defined in the future to hold the
>   normalized OpenID Identifier.
> 
> -------
> Of course instead of talking about OpenID identifiers (as URIs) we would be talking about resource owner identifiers, for example, the "Principal" defined in Section 4.1.6 of JWT (in case a JSON-based structure is used to encode information, as it was done with OpenID Connect). Note that the JWT spec does not define the syntax of the principal identifier. 
> 
> Section 3.2.1 and Section 3.2.2 of the current OAuth SASL draft would be impacted. 
> 
> Does this sound reasonable? 
> 
> Ciao
> Hannes
> 
> On Nov 20, 2012, at 2:53 AM, William Mills wrote:
> 
> > We can strike that second sentence if you want, it was there to try to clarify, and if it's not doing that kill it. 
> > 
> > 
> > From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
> > To: kitten@ietf.org 
> > Sent: Sunday, November 18, 2012 11:43 PM
> > Subject: [kitten] Updating OAuth SASL
> > 
> > Hi all, 
> > 
> > I have incorporated Alexey's comments into the draft and also my own earlier review comments. 
> > Here is the current snapshot:
> > https://github.com/hannestschofenig/tschofenig-ids/blob/master/sasl-oauth/draft-ietf-kitten-sasl-oauth-09.txt
> > 
> > There is one issue that Alexey raised, which I still have to understand better myself, namely:
> > 
> > -----
> > 
> > 3.2.2.  Canonicalization
> > 
> >  The identity asserted by the OAuth authorization server is canonical
> >  for display.  The server MAY provide a different canonical form based
> >  on local data.
> > 
> > I don't understand the second sentence. SASL server? How can it do that?
> > 
> > ------
> > 
> > Ciao
> > Hannes
> > 
> > _______________________________________________
> > Kitten mailing list
> > Kitten@ietf.org
> > https://www.ietf.org/mailman/listinfo/kitten
> > 
> > 
> 
> 
> 