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

[Eran Hammer-Lahav <[e-mail]>]

I read the minutes.

I don't need to be on the call to present my views on how to proceed. That's not how the IETF operates. I have been expressing my views for the past year, right here on the list. I didn't see any consensus call from the chairs about taking this approach (instead of others).

I also noticed the lack of follow up since the call with any kind of discussion on use cases.

I have asked the chairs to provide a place to discuss technical issues and that is what this second call is about. Unless the chairs decide to change it.

EHL

> -----Original Message-----
> From: Dick Hardt [mailto:[e-mail]]
> Sent: Wednesday, February 03, 2010 9:43 AM
> To: Eran Hammer-Lahav
> Cc: Anthony Nadalin; OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> Eran,
> 
> Both Tony and I are explaining to you what happened on the call. If you had
> been on the call, you could have presented your view on how to proceed
> with the calls.
> While you may have a different opinion on how to proceed (which I am NOT
> arguing with), arguing with us on what happened on the call seems pointless.
> 
> -- Dick
> 
> On 2010-02-03, at 9:34 AM, Eran Hammer-Lahav wrote:
> 
> > Hi Anthony,
> >
> > The problem with this approach is that it hasn't worked (multiple times)
> before because no one ever wants to do the work of collecting and writing
> the use cases. What we get instead are short cryptic lists and pointers to
> edge cases. We have a good grasp on how OAuth 1.0 is used and its
> limitations as addressed by the WRAP draft.
> >
> > The best use of my time is to continue working on the drafts and asking
> technical questions whenever a decision is needed. If and when someone
> writes use cases, I will review those and see if they are supported by the
> drafts.
> >
> > I will leave it up to the chairs to decide how they want to guide the working
> group.
> >
> > EHL
> >
> >> -----Original Message-----
> >> From: Anthony Nadalin [mailto:[e-mail]]
> >> Sent: Wednesday, February 03, 2010 9:02 AM
> >> To: Eran Hammer-Lahav; Dick Hardt
> >> Cc: OAuth WG
> >> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
> >>
> >> I would tend to agree with Dick based upon the last call and where
> >> that was heading. I believe that Eve had some use cases to share
> >> around UMA
> >>
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Eran Hammer-Lahav
> >> Sent: Wednesday, February 03, 2010 8:41 AM
> >> 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
> >
> > _______________________________________________
> > OAuth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth