Subject: Re: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-12

From: Ryan Troll <[email-masked]>
Date: Tue, 18 Feb 2014 21:07:18 -0800

Version -13 was released, and "user=" is not present.

Can this be placed back in prior to approval as an RFC?  It's optional,
present to encourage implementors to use the same field name for this data
(if required by their implementation), and was previously part of the
GS2-header which was recently removed.

-R

On Mon, Jan 6, 2014 at 4:25 PM, Bill Mills <[email-masked]> wrote:

> That said, your extant implementation might argue for leaving the GS2
> header in there...
>
>
>
> -bill
>
>
> --------------------------------
> William J. Mills
> "Paranoid" Yahoo!
>
>
>
>   On , Bill Mills <[email-masked]> wrote:
>  Now that it's not duplicating the gs2 stuff it makes some sense.  It can
> be easily added back.
>
> Any objection to adding the "user" field back in?
>
> -bill
>
>
> --------------------------------
> William J. Mills
> "Paranoid" Yahoo!
>
>
>
>   On Monday, January 6, 2014 4:10 PM, Ryan Troll <[email-masked]>
> wrote:
>
>
> MAJOR:
>
> * Removing the GS2-header (which was done in revision -11) also removed
> the ability for the client to specify an authorization identity.  If the
> lack of an authorization identity is acceptable (and I suspect it is not
> for some), then the document needs to state these mechanisms do not support
> authz-id.
>
>
>
> The loss of the authz-id is a problem for us.  Last year we discussed the
> use case with the list, came to the conclusion that what our use case
> needed was access to the authz-id; and agreed that we'd pull it from the
> GS2-header.
>
> Now that the GS2-header is gone, it would be beneficial to provide a
> standard, but optional, way for clients to provide the authz-id to the
> service.  This would ensure compatibility across services which require the
> authz-id; while not requiring it for *all* SASL-OAuth clients.
>
> The original proposal had been to define a reserved keyword ("user") which
> could be part of the initial client response.  Should this be re-added?
>
> -R
>
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>
>
>
>
>

---

From: Bill Mills <[email-masked]>
Date: Tue, 18 Feb 2014 21:38:59 -0800

My error, I was supposed to put it back.

Can we fix it?

-bill

--------------------------------
William J. Mills
"Paranoid" Membership Yahoo!

On Tuesday, February 18, 2014 9:07 PM, Ryan Troll <[email-masked]> wrote:

Can this be placed back in prior to approval as an RFC?  It's optional, present to encourage implementors to use the same field name for this data (if required by their implementation), and was previously part of the GS2-header which was recently removed.

-R

That said, your extant implementation might argue for leaving the GS2 header in there...
>Now that it's not duplicating the gs2 stuff it makes some sense.  It can be easily added back.
>
>
>
>On Monday, January 6, 2014 4:10 PM, Ryan Troll <[email-masked]> wrote:
> 
>
>>MAJOR:
>>
>>* Removing the GS2-header (which was done in revision -11) also removed the ability for the client to specify an authorization identity.  If the lack of an authorization identity is acceptable (and I suspect it is not for some), then the document needs to state these mechanisms do not support authz-id.
>
>
>
>
>The loss of the authz-id is a problem for us.  Last year we discussed the use case with the list, came to the conclusion that what our use case needed was access to the authz-id; and agreed that we'd pull it from the GS2-header.
>
>
>Now that the GS2-header is gone, it would be beneficial to provide a standard, but optional, way for clients to provide the authz-id to the service.  This would ensure compatibility across services which require the authz-id; while not requiring it for *all* SASL-OAuth clients.
>
>
>The original proposal had been to define a reserved keyword ("user") which could be part of the initial client response.  Should this be re-added?
>
>
>-R
> 
>