Subject: [kitten] Updating OAuth SASL

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 19 Nov 2012 09:43:32 +0200

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Nov 2012 11:39:53 +0000

> Hi all,
Hi Hannes,
> There is one issue that Alexey raised, which I still have to understand better myself, namely:
Are you agreeing with me that the last sentence is not clear?

I suspect it is wrong and should be deleted, but whoever wrote it should 
comment on that.

---

From: William Mills <[email-masked]>
Date: Mon, 19 Nov 2012 16:51:49 -0800 (PST)

The SASL server might have a display name for a local mailbox for example, so it might display a different display name than the one provided.

>________________________________
> From: Alexey Melnikov <[email-masked]>
>To: Hannes Tschofenig <[email-masked]> 
>Cc: [email-masked] 
>Sent: Monday, November 19, 2012 3:39 AM
>Subject: Re: [kitten] Updating OAuth SASL
> 
>_______________________________________________
>Kitten mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/kitten
>
>
>

---

From: William Mills <[email-masked]>
Date: Mon, 19 Nov 2012 16:53:02 -0800 (PST)

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 <[email-masked]>
>To: [email-masked] 
>Sent: Sunday, November 18, 2012 11:43 PM
>Subject: [kitten] Updating OAuth SASL
> 
>Hi all, 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Nov 2012 16:38:49 +0200

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

---

From: William Mills <[email-masked]>
Date: Thu, 22 Nov 2012 16:17:11 -0800 (PST)

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

>To: William Mills <[email-masked]>; Alexey Melnikov <[email-masked]> 
>Cc: Hannes Tschofenig <[email-masked]>; [email-masked] 
>Sent: Thursday, November 22, 2012 6:38 AM

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 23 Nov 2012 09:52:27 +0200

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