Indeed. Feel free to start separate threads on each, add them to the issue tracker, etc. I'll be mostly offline (travelling) for the next 36 hours but will try to catch up then.
Thanks to everyone who participated in today's call. On 2/4/10 4:26 PM, Eran Hammer-Lahav wrote: > All these items are still open for discussion, even if we didn't get to them > on the call. > > EHL > >> -----Original Message----- >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@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-boun...@ietf.org [mailto:oauth-boun...@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 >>>
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
