Hiya,
Sorry - I should have posted the announce here too. Not doing so was just an oversight. Discussion of overlaps between the newly proposed and existing work is a fine topic for the new list I'd say. But better there than here. Cheers, S On 6 December 2014 11:42:57 GMT+00:00, Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: >I think it should be the responsibility of document authors to read the >the state of the art to avoid re-inventing the wheel (particularly >since >their co-workers have been heavily involved in the work). > >It is not true that we have been waiting for 4 years for this now since >they have changed their solution approach many times and the use of the >raw public key in combination with the PoP solution would have given a >complete solution. > >Ciao >Hannes > > >On 12/06/2014 11:09 AM, John Bradley wrote: >> They have examples of how it could be used in OAuth and Connect. >They didn't look at what we were doing with PoP so the examples don't >line up. >> >> That is why it is important to keep on top of this so that it is the >OAuth WG that is defining how this binding mechanism is used in OAuth >and JWT. >> >> The specs themselves are, or should be independent of token type. >> >> We have been waiting for TLS to produce this for around 4 years now. > It is not really new work, mostly a change of venue to make progress. >> >> All of this was discussed at the last IETF meeting. I thought a >significant number of people from the OAuth WG were in the room. >> >> John B. >>> On Dec 6, 2014, at 6:28 AM, Hannes Tschofenig ><hannes.tschofe...@gmx.net> wrote: >>> >>> I agree with Phil. As currently described it replicates a lot of the >>> work we have done in PoP. >>> >>> Ciao >>> Hannes >>> >>> On 12/06/2014 09:52 AM, John Bradley wrote: >>>> No, this is the the work formerly known as origin bound >certificates & Channel ID. We need this to bind id_tokens and or >access tokens to TLS sessions. >>>> >>>> So it is an alternative TLS binding mechanism. We still need to >describe how to use it with OAuth and JWT. >>>> >>>> It is a building block we can use for PoP. >>>> >>>> John B. >>>>> On Dec 5, 2014, at 10:48 PM, Phil Hunt <phil.h...@oracle.com> >wrote: >>>>> >>>>> Doesn't that duplicate our current work? >>>>> >>>>> Phil >>>>> >>>>>> On Dec 5, 2014, at 11:17, Hannes Tschofenig ><hannes.tschofe...@gmx.net> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: [websec] unbearable - new mailing list to discuss better >than >>>>>> bearer tokens... >>>>>> Date: Fri, 05 Dec 2014 16:43:19 +0000 >>>>>> From: Stephen Farrell <stephen.farr...@cs.tcd.ie> >>>>>> Reply-To: Stephen Farrell <stephen.farr...@cs.tcd.ie> >>>>>> To: s...@ietf.org <s...@ietf.org>, websec <web...@ietf.org>, >>>>>> u...@ietf.org <u...@ietf.org>, ietf-http...@w3.org Group >>>>>> <ietf-http...@w3.org>, http-a...@ietf.org <http-a...@ietf.org> >>>>>> >>>>>> >>>>>> Hiya, >>>>>> >>>>>> Following up on the presentation at IETF-91 on this topic, [1] >>>>>> we've created a new list [2] for moving that along. The list >>>>>> description is: >>>>>> >>>>>> "This list is for discussion of proposals for doing better than >bearer >>>>>> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web >applications. >>>>>> The specific goal is chartering a WG focused on preventing >security >>>>>> token export and replay attacks." >>>>>> >>>>>> If you're interested please join in. >>>>>> >>>>>> Thanks to Vinod and Andrei for agreeing to admin the list. >>>>>> >>>>>> We'll kick off discussion in a few days when folks have had >>>>>> a chance to subscribe. >>>>>> >>>>>> Cheers, >>>>>> S. >>>>>> >>>>>> PS: Please don't reply-all to this, join the new list, wait >>>>>> a few days and then say what you need to say:-) >>>>>> >>>>>> [1] https://tools.ietf.org/agenda/91/slides/slides-91-uta-2.pdf >>>>>> [2] https://www.ietf.org/mailman/listinfo/unbearable >>>>>> >>>>>> _______________________________________________ >>>>>> websec mailing list >>>>>> web...@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/websec >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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
