Thanks for having these conversations, Justin. It will be interesting to see
how they go.
As a co-editor, given that I was surprised that these numerous breaking changes
were checked in without me or the other editors being given a chance to review
them first, or for adequate discussion of them to occur by the working group, I
would request that the default action for any of the changes made for which
there isn't obvious consensus to keep be to back those breaking changes out
before the submission deadline in two weeks. Then we can start clean and only
add changes once it's clear that doing so improves consensus. (Obviously if a
change appears to have been clearly accepted by the working group, there's no
reason to remove it.)
Thanks,
-- Mike
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Justin Richer
Sent: Monday, February 11, 2013 1:11 PM
To: [email protected]
Subject: [OAUTH-WG] Recent changes to Registration
As many of you saw, last week I published a draft of the OAuth Dynamic Client
Registration spec [1] that made some fairly serious changes to how the protocol
works. It was my intent to distill many threads of conversation here on the
list into a full, workable protocol with a concrete document that we could
discuss. I believe that what I published did that, but I certainly don't think
that all of our work and discussion is done. It wasn't my intent to surprise
people with the draft (apparently I really did!), nor was it my intent to
simply dictate where the spec was going without any input from the working
group.
So to move the discussion forward in a very deliberate fashion, I'm going to be
starting a number of new threads for discussion on particular changes and
components to this spec so that we can discuss things and decide as a working
group what the best courses of action are. I'll lay out what the issues are,
what -05 says today, what the options are as I see them, and we I think can go
from there. The topics will be:
- JSON Encoding
- Endpoint Definition (& operation parameter)
- HAL _links structure and client self-URL
- RESTful client lifecycle management
- Client secret rotation
If you want to talk about the overall design and philosophy of the Registration
document, just reply to this email.
Of course, all of these interrelate in various ways, and everything must be
taken in the overall context, but I'm hoping that by splitting things up this
way we can focus the conversations better. I welcome all constructive
discussion, debate, and input. As an editor, I am particularly grateful for
anyone who wants to provide actual text for inclusion in the document itself,
and any pointers to implemented code for any of this.
The deadline for IETF86 is two weeks from now, and I want to have a version -06
or greater that incorporates all of the comments from these threads by then.
-- Justin
[1] http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-05
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
