In my opinion, dynamic client registration would allow us to drop public
client thus simplifying the core spec.
regards,
Torsten.
Am 15.03.2012 16:00, schrieb Eran Hammer:
I believe most do, except for the dynamic client registration. I don't have strong
objections to it, but it is the least important and least defined / deployed
proposal on the list. The AS->RS work is probably simpler and more useful at
this point.
EH
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Thursday, March 15, 2012 4:47 AM
To: ext Blaine Cook; Hannes Tschofenig
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
Hi Blaine,
These are indeed good requirements you stated below.
When you look at the list of topics do you think that the proposed items
indeed fulfill them?
Ciao
Hannes
-----Original Message-----
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of ext Blaine Cook
Sent: Thursday, March 15, 2012 1:31 PM
To: Hannes Tschofenig
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] OAuth WG Re-Chartering
On 14 March 2012 20:21, Hannes Tschofenig
<hannes.tschofe...@gmx.net>
wrote:
So, here is a proposal:
[Editor's Note: New work for the group. 5 items maximum! ]
Aug. 2012 Submit 'Token Revocation' to the IESG for consideration
as a Proposed Standard
Nov. 2012 Submit 'JSON Web Token (JWT)' to the IESG for
consideration as a Proposed Standard
Nov. 2012 Submit 'JSON Web Token (JWT) Bearer Token Profiles for
OAuth 2.0' to the IESG for consideration
Jan. 2013 Submit 'OAuth Dynamic Client Registration Protocol' to
the IESG for consideration as a Proposed Standard
Sep. 2012 Submit 'OAuth Use Cases' to the IESG for consideration
as an Informational RFC
This looks great to me.
I have serious concerns about feature-creep, and think that the OAuth
WG should strongly limit its purview to these issues. In general, I
think it prudent for this working group in particular to consider
standardisation of work only under the following criteria:
1. Proposals must have a direct relationship to the mechanism of OAuth
(and not, specifically, bound to an application-level protocol).
2. Proposals must have significant adoption in both enterprise and
startup environments.
3. Any proposal must be driven based on a consideration of the
different approaches, as adopted in the wild, and strive to be a
better synthesis of those approaches, not a means to an end.
These are the constraints with which I started the OAuth project, and
they're more relevant than ever. I'd hate to see OAuth fail in the end
because of a WS-*-like death by standards-pile-on.
b.
_______________________________________________
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
