Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an authentication challenge?

From: "Manger, James H" <[email-masked]>
Date: Thu, 4 Feb 2010 00:37:51 +1100

An authentication challenge (WWW-Authenticate header) defined in a spec for an authentication mechanism should be present, but only with details specific to that mechanism (eg list of MAC algorithms).

I think there should be a totally separate WWW-Authenticate header specifically saying "a delegation flow can be used to access this resource". It should include details such as the URI to redirect the user to.

We really need this if we want to offer a web-style protocol with any semblance of interoperability. If we omit it because "clients need to know lots of other API-specific details anyway" then we wont have a path to get past that limitation in future.

-- 
James Manger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Eran Hammer-Lahav
> Sent: Thursday, 28 January 2010 2:12 PM
> To: OAuth WG ([email-masked])
> Subject: [OAUTH-WG] What are the primary criteria in issuing an
> authentication challenge?
> 
> An authentication challenge (to make sure we are all on the same page)
> is something the server sends to the client when denying access to a
> protected resource. The challenge can be as simple as "use Basic", or
> complex as "use Digest with the following parameters". OAuth 1.0
> doesn't really use a challenge because it was created for cases where
> the API calls are preconfigured and hardcoded into the client. The
> client should never receive an OAuth challenge the way the protocol was
> originally designed.
> 
> In my token authentication draft I tried to propose multiple mechanisms
> (not fully baked yet) for issuing a challenge and allowing the client
> to figure out what to do next. Before producing another draft, it is
> important to figure out what challenge model we want to use. Here are
> the general options I came up with:
> 
> 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is left
> on its own to figure out what to do next.
> 
> 2. Basic / OAuth 1.0 + simple discovery - Say "use Token and if you
> need a new token go there". It is still not clear how this will help
> the client given that getting a token is likely it include many
> different options, and to fully address this we need to dig deep into
> discovery which was left out of scope.
> 
> 3. Token attributes - the server informs the client of the kind of
> tokens accepted (based on their cryptographic properties or the
> resource-set/realm they are good for). This is just like #2 but with
> the ability for the server to support more than one token type per
> resource.
> 
> Question: Is the ability for a single token-protected resource to
> support more than one token type (say Plain+SSL *and* HMAC-256) part of
> our requirements? If not, there is no reason at all for the challenge
> to include anything other than #1 or #2 (probably defined as a future
> extension).
> 
> EHL
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 09:46:06 -0700

It doesn't feel like we have much interest at this level of interoperability at this point.

EHL

> From: Manger, James H [mailto:[email-masked]]
> Sent: Wednesday, February 03, 2010 5:38 AM
> To: Eran Hammer-Lahav; OAuth WG ([email-masked])
> Subject: RE: [OAUTH-WG] What are the primary criteria in issuing an
> An authentication challenge (WWW-Authenticate header) defined in a spec
> for an authentication mechanism should be present, but only with details
> specific to that mechanism (eg list of MAC algorithms).
> 
> I think there should be a totally separate WWW-Authenticate header
> specifically saying "a delegation flow can be used to access this resource". It
> should include details such as the URI to redirect the user to.
> 
> We really need this if we want to offer a web-style protocol with any
> semblance of interoperability. If we omit it because "clients need to know
> lots of other API-specific details anyway" then we wont have a path to get
> past that limitation in future.
> 
> 
> --
> James Manger
> 
> > client should never receive an OAuth challenge the way the protocol
> > was originally designed.
> >
> > In my token authentication draft I tried to propose multiple
> > mechanisms (not fully baked yet) for issuing a challenge and allowing
> > the client to figure out what to do next. Before producing another
> > draft, it is important to figure out what challenge model we want to
> > use. Here are the general options I came up with:
> >
> > 1. Basic / OAuth 1.0 style - Simply say "use Token". The client is
> > left on its own to figure out what to do next.
> >
> > support more than one token type (say Plain+SSL *and* HMAC-256) part
> > of our requirements? If not, there is no reason at all for the
> > challenge to include anything other than #1 or #2 (probably defined as
> > a future extension).
> >
> > EHL
> >

---

From: Joseph Anthony Pasquale Holsten <[email-masked]>
Date: Wed, 3 Feb 2010 20:11:36 -0600

A self fulfilling prophecy.

Who isn't interested? Client authors or service providers with an incentive to lock people in? If you work at microsoft or google or yahoo or facebook, you might consider asking people like ping.fm how much they care about interoperability. And maybe ask why the people who are supposed to be consuming these services aren't active on these lists.
--
j

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 19:16:45 -0700

You are going too far. I meant the people on this list. That's the only group that matters.

EHL

> Of Joseph Anthony Pasquale Holsten
> Sent: Wednesday, February 03, 2010 6:12 PM
> Subject: Re: [OAUTH-WG] What are the primary criteria in issuing an
> Who isn't interested? Client authors or service providers with an incentive to
> lock people in? If you work at microsoft or google or yahoo or facebook, you
> might consider asking people like ping.fm how much they care about
> interoperability. And maybe ask why the people who are supposed to be
> consuming these services aren't active on these lists.
> --
> j
> 
> >> An authentication challenge (WWW-Authenticate header) defined in a
> >> spec for an authentication mechanism should be present, but only with
> >> details specific to that mechanism (eg list of MAC algorithms).
> >>
> >> specifically saying "a delegation flow can be used to access this
> >> resource". It should include details such as the URI to redirect the user to.
> >>
> >> semblance of interoperability. If we omit it because "clients need to
> >> know lots of other API-specific details anyway" then we wont have a
> >> path to get past that limitation in future.
> >>
> >>
> >> --
> >> James Manger
> >>
> >>> From: [email-masked] [mailto:[email-masked]] On
> >>> Behalf Of Eran Hammer-Lahav
> >>> An authentication challenge (to make sure we are all on the same
> >>> page) is something the server sends to the client when denying
> >>> access to a protected resource. The challenge can be as simple as
> >>> "use Basic", or complex as "use Digest with the following
> >>> parameters". OAuth 1.0 doesn't really use a challenge because it was
> >>> created for cases where the API calls are preconfigured and
> >>> hardcoded into the client. The client should never receive an OAuth
> >>> challenge the way the protocol was originally designed.
> >>>
> >>> mechanisms (not fully baked yet) for issuing a challenge and
> >>> allowing the client to figure out what to do next. Before producing
> >>> another draft, it is important to figure out what challenge model we
> >>> want to use. Here are the general options I came up with:
> >>>
> >>> different options, and to fully address this we need to dig deep
> >>> into discovery which was left out of scope.
> >>>
> >>> challenge to include anything other than #1 or #2 (probably defined
> >>> as a future extension).
> >>>
> >>> EHL
> >>>

---

From: Joseph Anthony Pasquale Holsten <[email-masked]>
Date: Wed, 3 Feb 2010 20:53:55 -0600

Please consider my position retracted.
--
j

---

From: John Panzer <[email-masked]>
Date: Wed, 3 Feb 2010 21:22:45 -0800

Au contraire (speaking only for myself).

On Wednesday, February 3, 2010, Eran Hammer-Lahav <[email-masked]> wrote:
> ht <https://www.ietf.org/mailman/listinfo/oauth>

-- 
--
John Panzer / Google
[email-masked] / abstractioneer.org / @jpanzer

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 23:35:41 -0700

Just to be clear, I was referring to the case where a client can figure out how to obtain authorization and then authenticate without any pre-configuration. This means giving a discovery flow for each type of authorization option (desktop, mobile, web, etc.) with all the parameters needed for each (pop-up size, redirection URIs, extension parameters, digital TOS).

EHL

> From: John Panzer [mailto:[email-masked]]
> Sent: Wednesday, February 03, 2010 9:23 PM
> To: Eran Hammer-Lahav
> Cc: Manger, James H; OAuth WG ([email-masked])
> >> > parameters". OAuth 1.0 doesn't really use a challenge because it
> >> > was created for cases where the API calls are preconfigured and
> >> > another draft, it is important to figure out what challenge model
> >> > we want to use. Here are the general options I came up with:
> >> >
> >> > need a new token go there". It is still not clear how this will
> >> > help the client given that getting a token is likely it include
> >> > many different options, and to fully address this we need to dig
> >> > deep into discovery which was left out of scope.
> >> >
> >> > resource-set/realm they are good for). This is just like #2 but
> >> > with the ability for the server to support more than one token type
> >> > per resource.
> >> >
> >> > support more than one token type (say Plain+SSL *and* HMAC-256)
> >> > part of our requirements? If not, there is no reason at all for the

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 04 Feb 2010 10:50:30 -0700

<hat type='individual'/>

If James is interested in this then he can write an Internet-Draft.
That's how the IETF works. :)

IMHO such a WWW-Authenticate header might be quite useful, if we think
that random entities might try to access a resource that is protected
and therefore might need a way to know that they can access the resource
via a delegation flow. I'm not sure how likely that is, though.