Subject: Re: [kitten] Identities Re: Comma vs. %x01 Re: OAuth SASL draft -05

From: John Bradley <[email-masked]>
Date: Thu, 20 Sep 2012 19:25:59 -0300

authZ ID is the entity you are acting on behalf of.

In XMPP I understand that to be I am logging in with my authcid and password and want to act as the authzid if my authcid credential allows it.

I don't see how that would ever be the client_id.  

I can see having the OAuth token conveying that my account X has granted access to the client to access three mailboxes and each of those mailboxes may be identified by two email addresses.

I still think that a oauth account may have more than one resource of a given type (mail-box) so unless you restrict that you need to specify the resource someplace.

That is not the same as authz which is the identity you want to act as.  For IMAP it may be but we don't want to limit the oauth mechanism to a single protocol.

John B.

On 2012-08-29, at 12:34 AM, William Mills <[email-masked]> wrote:

> Just to be clear it is possible in OAuth to have *both* a client ID which would equate to an authZ ID and a ID in the token which would be an authN ID.   All this info might be carried in a Bearer token, or explicitly called out in OAuth 1.0a as the oauth_client.  If the client ID represents something  like a desktop client it (i.e. Flickr Uploadr client and mobile clients now) then that ID isn't probably really useful because it's effectively a user agent.  On the other hand it might be the client ID of a 3rd party in a 3 legged relationship, in which case it really is what we want.  I was leaving that the to the server to determine.
> 
> 
> From: Nico Williams <[email-masked]>
> To: "Cantor, Scott" <[email-masked]> 
> Cc: "[email-masked]" <[email-masked]> 
> Sent: Tuesday, August 28, 2012 9:05 PM
> Subject: Re: [kitten] Comma vs. %x01 Re: OAuth SASL draft -05
> 
> On Tue, Aug 28, 2012 at 10:59 PM, Cantor, Scott <[email-masked]> wrote:
> > On 8/28/12 11:54 PM, "Nico Williams" <[email-masked]> wrote:
> >>
> >>OK, let's say that there is a GSS mechanism such that it makes no
> >>sense to assert an authz-id when using it as a SASL/GS2 mechanism.
> >
> > I don't think there's any obvious reason for that here.
> 
> I don't see that either.  Just trying to think this through.
> 
> >>What's the problem?  Well, we need to say what happens if an authz-id
> >>is asserted nonetheless.  We can say that the server "MUST fail the
> >>authentication attempt", or that it "MUST ignore the authz-id
> >>assertion", or perhaps something else.
> >
> > As I suspected, and Simon/Luke noted, you can't mandate that without
> > breaking existing GS2 code.
> 
> Good point.
> 
> I think the best thing to do is to say that this is a SASL/GS2 (and
> therefore GSS) mechanism and then say *noting* about the SASL
> authz-id.
> 
> Nico
> --
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
> 
> 
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: William Mills <[email-masked]>
Date: Fri, 21 Sep 2012 08:28:41 -0700 (PDT)

OK, so after all this time, I have them reversed.  In any event, the application will have to use a mechanism that allows something other than the authcid to be communicated if it wants to get to additional information out of the OAuth context.

>________________________________
> From: John Bradley <[email-masked]>
>To: William Mills <[email-masked]> 
>Cc: Nico Williams <[email-masked]>; "Cantor, Scott" <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, September 20, 2012 3:25 PM
>Subject: Re: [kitten] Identities Re:  Comma vs. %x01 Re: OAuth SASL draft -05
> 
>
>>>________________________________

---

From: Nico Williams <[email-masked]>
Date: Fri, 21 Sep 2012 10:31:56 -0500

On Fri, Sep 21, 2012 at 10:28 AM, William Mills <[email-masked]> wrote:
> OK, so after all this time, I have them reversed.  In any event, the
> application will have to use a mechanism that allows something other than
> the authcid to be communicated if it wants to get to additional information
> out of the OAuth context.

And today that would be the authz-id.

Nico
--