This is a small batch of updates to the Dynamic Registration Management
experimental draft to address comments from the shepherd writeup.
Source is in GitHub:
https://github.com/jricher/oauth-spec
— Justin
On Dec 6, 2014, at 11:38 PM,
wrote:
>
> A New Internet-Draft is available from th
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Dynamic Client Registration Management
Protocol
Authors : Justin Richer
… and I just noticed hanging text at the top of section 2.2 due to the JWT
claims edit. My working copy has removed the extraneous text “Several of these”.
Also, as always, latest XML is up on GitHub:
https://github.com/jricher/oauth-spec
— Justin
On Dec 6, 2014, at 10:34 PM, Justin Richer wro
Small update to introspection, now the returned values reference the JWT claims
specifically (as requested). Also updated the HTTP and HTML references.
No normative changes.
— Justin
On Dec 6, 2014, at 10:32 PM, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the o
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : OAuth 2.0 Token Introspection
Author : Justin Richer
Filename: draft-
:-)
Phil
> On Dec 6, 2014, at 08:37, Stephen Farrell wrote:
>
>
>
> Hi Phil,
>
> Good points that need discussing but I'd suggest we give the new
> list a few days to allow folks to subscribe and then have that
> discussion.
>
> Thanks,
> S.
>
>> On 06/12/14 16:08, Phil Hunt wrote:
>> On t
Hi Phil,
Good points that need discussing but I'd suggest we give the new
list a few days to allow folks to subscribe and then have that
discussion.
Thanks,
S.
On 06/12/14 16:08, Phil Hunt wrote:
> On the surface (as currently presented) this work appears to duplicate the
> POP work going on
On the surface (as currently presented) this work appears to duplicate the POP
work going on in OAuth. The key difference is that this work is focused on
using ALPN to bind tokens to the TLS channel. From a use case perspective it is
very close to OAuth POP, and a specific use case of the curre
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, Hanne
On Wed, Dec 3, 2014 at 3:37 AM, wrote:
> Send OAuth mailing list submissions to
> oauth@ietf.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/oauth
> or, via email, send a message with subject or body 'help' to
> oau
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
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.
Th
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
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 u
14 matches
Mail list logo
