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
> 
> 