Hi Adam, we had 3 conference calls to discuss the security requirements and now we have started the design team work. In fact the first call of the design team starts in 45 mins and the conference call details have been sent to the list. You are also welcome to join; it is an open design team.
The security requirements document had been updated and I have distributed the meeting minutes to the list. All the drafts will be refreshed in time for the submission deadline. Ciao Hannes On Feb 4, 2013, at 7:02 PM, Lewis Adam-CAL022 wrote: > Speaking of ... what is the status of the HOK work? The last draft has > expired and its fallen off of the OAuth page now. > > > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of > Sergey Beryozkin > Sent: Monday, February 04, 2013 10:58 AM > To: oauth@ietf.org > Subject: Re: [OAUTH-WG] I'm concerned about how the sniffability of oauth2 > requests > > On 04/02/13 16:27, William Mills wrote: >> There are two efforts at signed token types: MAC which is still a >> possibility if we wake up and do it, > > I'd rephrase it slightly differently, it is a possibility right now, > OAuth2 supports custom tokens, the fact that OAuth2 may not formally > approve MAC won't preclude the use of MAC in the OAuth2 compliant manner. > > Of course OAuth2 putting a stamp of approval will make it more visible, > without it, the existing MAC draft issues (if any) will end up being > addressed at the specific implementations level only - not ideal for the > community at large but it is up to OAuth2... > > Cheers, Sergey > > >> and the "Holder Of Key" type tokens. >> >> There are a lot of folks that agree with you. >> >> ------------------------------------------------------------------------ >> *From:* L. Preston Sego III <lpse...@gmail.com> >> *To:* oauth@ietf.org >> *Sent:* Friday, February 1, 2013 7:37 AM >> *Subject:* [OAUTH-WG] I'm concerned about how the sniffability of oauth2 >> requests >> >> In an oauth2 request, the access token is passed along in the header, >> with nothing else. >> >> As I understand it, oauth2 was designed to be simple for everyone to >> use. And while, that's true, I don't really like how all of the security >> is reliant on SSL. >> >> what if an attack can strip away SSL using a tool such as sslstrip (or >> whatever else would be more suitable for modern https)? They would be >> able to see the access token and start forging whatever request he or >> she wants to. >> >> Why not do some sort of RSA-type public-private key thing like back in >> Oauth1, where there is verification of the payload on each request? Just >> use a better algorithm? >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
