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

All these items are still open for discussion, even if we didn't get to them on the call.

EHL

> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Tuesday, February 02, 2010 11:25 PM
> To: Peter Saint-Andre; OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> 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: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth