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

[Blaine Cook <[e-mail]>]

I've started a wiki page here:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthFeatureMatrix

to pull in the features people think are important, and give us both
some way of collecting that data over time and expressing what's
present or missing from each protocol & proposal. Despite being called
FeatureMatrix, please treat it as a Use Case Matrix.

If people don't want to go in and edit the wiki table (I don't blame
you) please send your use cases to me ([e-mail]) and I will
fill them out on the wiki for you. If you have blog posts or links to
pre-existing use cases or features, please include those as they will
help clarify the features.

b.

ps. the wiki won't let me put in a bookmarklet to make the text entry
not suck (i.e., use a fixed-width font), so here's one in case you do
decide to edit the wiki:

javascript:document.getElementById('text').style.fontFamily='courier'

On 3 February 2010 17:59, Eran Hammer-Lahav <[e-mail]> wrote:
> 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
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>