Hi Hannes, thank you very much for the response and it is very useful to have such detailed information. thank you again for that. I am now reading about PoP and it is very interesting and also seeing HTTP signature as well. Our requirement in short - to achieve seamless authentication and authorization among HTTP - REST based web services within a protected network with a secure channel for communication, without human intervention and without compromise on the time taken to process each request. Kindly let me know if you need further details . thanks again -rex
On Wed, Sep 10, 2014 at 9:26 PM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi Rex, > > the document <draft-ietf-oauth-v2-http-mac-05> has been superseded by > the PoP work (which was subsequently split into various other documents). > > That, however, does not mean that the content is dead. The mechanism for > the authorization server to convey the symmetric key to the client is > now documented in <draft-ietf-oauth-pop-key-distribution>. The high > level description / overview is now documented in > <draft-ietf-oauth-pop-architecture>. The actual mechanism for the client > to apply the key to the request to the resource server is now documented > in <draft-ietf-oauth-signed-http-request>. > > While < draft-ietf-oauth-signed-http-request> today is different to the > mechanism described in <draft-ietf-oauth-v2-http-mac-05> it also has to > be said that it is the weakest document in the entire document set at > the moment. > > So, there is still a chance to incorporate your design requirements into > the appropriate parts of the work since the work is still in progress. > > It would be good to know what your requirements/interests are. > > Ciao > Hannes > > > On 09/10/2014 11:49 AM, Sergey Beryozkin wrote: > > Hi > > On 10/09/14 09:57, Rex Albert wrote: > >> > >> > >> Hi, > >> We are looking at implementing OAUTHV2-HTTP-MAC whose draft is in an > >> expired > >> state.(http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-05) Is > >> it dead or is it going to be a standard anytime? or are we going to > >> implement at our own risk? or is there a better standard/draft ( alive ) > >> which might supersede this draft ? > > > > It's not going to be revived. Does not mean though one can not use the > > idea for implementing custom OAuth2 token schemes, IMHO it was a very > > simple and effective 'PoP' approach, and it is easy to document and > > support. FYI, we support a Hawk scheme (not part of OAuth2 work at all, > > kind of 'draft-ietf-oauth-v2-http-mac-06') as an access token scheme in > > our project. > > > > As far as I understand new proof-of-possession documents the group is > > working upon will offer the alternative standard solutions. > > > > Cheers, Sergey > > > >> > >> thank you for your time. > >> I am a newbie to the IETF draft process and kindly excuse my naivety. > >> -rex > >> > >> > >> > >> _______________________________________________ > >> 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
