Re: [OAUTH-WG] proposed agenda for second interim meeting

["Vrancken Bart bv" <[e-mail]>]

Hi folks,

In the beginning of December, I posted 2 use cases for multi-level
delegation, but I didn't receive a lot of feedback there:
http://www.ietf.org/mail-archive/web/oauth/current/msg00807.html

Please feel free to provide feedback, now we are discussing about use
cases.

Best regards,

Bart Vrancken

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Eran Hammer-Lahav
Sent: woensdag 3 februari 2010 17:41
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting

Has anyone gathered and reviewed use cases? I haven't seen much of that
showing up on the list. From my experience, asking people for use cases
rarely works, unless someone is willing to do the work and collect them
(and so far I haven't heard from such volunteer). I much prefer the
process in which we produce a technical document based on OAuth 1.0 and
the new requirements as defined by WRAP, and discuss use cases as a
property of the technical attributes of this draft.

Of course, you don't have to agree with me, but that puts the burden of
producing use cases documentation on you and others interested in taking
that approach. We certainly have room for both, and keep in mind that my
token draft is not (yet) a working group item.

The indication I received from many of the active members of this list
is that we have a strong desire to show up at Anaheim with two stable
drafts. I think we are very close to getting the authentication piece
done following much of OAuth 1.0 functionality (only cleaner and better
structures), as well as treating bearer tokens as first class citizens.
Given that no one has started a discussion about the delegation flows to
include, I doubt we will have a stable second draft, but I plan on
getting the authentication piece stable in time.

It has also been my experience over the past two years that the biggest
challenge is to figure out the authentication piece. The 'go get a
token' piece tends to be much easier to agree on. If we get the
authentication draft to a stable place, my intention is to leave it
there and focus on the second part and come back to it as the delegation
requirements become clearer (if changes are needed). But at least it
gives us something stable to build upon.

EHL

> -----Original Message-----
> From: Dick Hardt [mailto:[e-mail]]
> Sent: Wednesday, February 03, 2010 7:02 AM
> To: Eran Hammer-Lahav
> Cc: Peter Saint-Andre; OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> Hi Eran
> 
> I think it is a little early in our phone discussions to get into
technical details.
> The next step according to the last call was to gather and review use
cases.
> Without rough consensus on what problem we are solving, your points
> below (which all do need to be discussed at some point) is just moving
> around deck chairs on the Titanic.
> 
> -- Dick
> 
> On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:
> 
> > Please add:
> >
> > - Discuss Adobe's recent request to allow excluding the host/port
from the
> signed message.
> >
> > - With regards to #4, how should the challenge identify the token to
be
> used (realm comes free, do we need another)?
> >
> > - Should a single token support multiple signature algorithms? This
has
> implications as to the information the client has to include with the
request
> (the algorithm used, etc.).
> >
> > - Where should the token structure live? OAuth 1.0 includes two
response
> parameters (token and token_secret). However, since we are now moving
> towards having the algorithm part of the token definition, as well as
duration
> and other attributes, the server will need to provide this information
to the
> client. This calls for a simple schema (can be any format but need to
agree to
> consistent names). It is currently part of the
authorization/delegation draft
> (implicitly), but we should discuss moving it to the authentication
draft since
> that's where it is used (the authorization draft simply hands those
"things"
> out).
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Peter Saint-Andre
> >> Sent: Tuesday, February 02, 2010 9:15 PM
> >> To: OAuth WG
> >> Subject: [OAUTH-WG] proposed agenda for second interim meeting
> >>
> >> <hat type='chair'/>
> >>
> >> At the first interim meeting, we didn't get through our agenda:
> >>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html
> >>
> >> Therefore I propose that this time we focus on some unfinished
> >> business, starting with the topic of authentication. I have
reviewed
> >> all of the related threads on the list and have come up with the
following
> *rough* agenda.
> >> Your feedback is welcome to improve this (a.k.a. "agenda
> >> bashing") either on the list or during the meeting.
> >>
> >> For logistics information, see here:
> >>
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html
> >>
> >> ******
> >>
> >> AGENDA
> >>
> >> Base proposal: draft-ietf-oauth-authentication-01
> >>
> >> Eran had hoped to push out a new version in time for our meeting,
but
> >> hasn't been able to get to it yet. However, I think we can continue
> >> to move forward with discussion. Feedback is welcome on the general
> >> approach, as well as specific open issues.
> >>
> >> Open issues....
> >>
> >> Issue #1: Request Signing vs. API Signing vs. Message Signing
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html
> >>
> >> 1a. Seeming consensus for message signing.
> >>
> >> 1b. No consensus yet on message format.
> >>    - JSON and textual key-value seem to be the leading candidates.
> >>
> >> 1c. Seeming consensus for multiple/extensible signature algorithms.
> >>    - HMAC-SHA1
> >>    - HMAC-SHA256
> >>    - RSASSA-PKCS1-v1.5-SHA256
> >>    - PLAIN over SSL/TLS
> >>
> >> But: which of these are Mandatory-to-Implement?
> >>
> >> Issue #2: Include the Normalized Request with the Request?
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html
> >>
> >> Seeming consensus to not include the normalized request (e.g.,
> >> signature string).
> >>
> >> Issue #3: Allow Secrets in Cleartext, or Require Channel
Encryption?
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html
> >>
> >> Seeming consensus that channel encryption is must-implement (which
> >> does not necessarily mean must-deploy).
> >>
> >> Issue #4: Authentication Challenges
> >> http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html
> >>
> >> If an authentication (access) request is unacceptable, how does the
> >> server tell the client how it can provide proper credentials (e.g.,
> >> by using a different algorithm)?
> >>
> >> Possible other topics:
> >>
> >> - Mutual auth?
> >>  http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html
> >>
> >> - Resource authorization?
> >>  http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html
> >>
> >> ******
> >>
> >> /psa
> >>
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth