Re: [kitten] Updating OAuth SASL

[William Mills <[e-mail]>]

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 <[e-mail]>
>To: William Mills <[e-mail]>; Alexey Melnikov <[e-mail]> 
>Cc: Hannes Tschofenig <[e-mail]>; [e-mail] 
>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 <[e-mail]>
>> To: [e-mail] 
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/kitten
>> 
>> 
>
>
>
>