[Openid-specs-ab] Other specs Review
Michael.Jones at microsoft.com
Thu Jun 6 09:19:24 UTC 2013
From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Wednesday, June 05, 2013 7:03 PM
To: openid-specs-ab at lists.openid.net
Subject: [Openid-specs-ab] Other specs Review
I have not checked the consistency with the most recent version of OAuth Registration.
The normative identifiers are consistent. There may be some wording differences that we should reconcile in both directions.
It has warning text about the relationship. If we are to announce that 2nd I-D is the stable one that will not change, we may want to remove the warning.
I think the warning should stay, as it's reflective of our intent to use the OAuth Dynamic Registration spec if it stabilizes in time.
At the very beginning, it is speaking of OAuth 2.0 protocol. IMHO, it should be replaced by its formal name: OAuth 2.0 Authorization Framework. This applies to all other documents.
This wording is intentional. "OAuth 2.0" actually refers to two documents - RFC 6749 and RFC 6750. Thus, replacing "OAuth 2.0", which is a commonly understood technical term, with a reference only to RFC 6749, would be incorrect. I have therefore not made this change in any document.
Basic and Implicit
Some of the changes to Message undoubtedly need to be propagated here.
I have done so all the time when changing text that occurs in multiple specs.
However, being more restrictive is fine here as it is a profile.
Also, omission of details are allowed here since it after all refers back to the base specs.
In this respect, they look pretty good.
One thing that I noticed, which I should have noticed a long time ago, is that it is stating normative requirements to the Server even though it claims that it is only applicable to Client. I suppose that is still OK.
That's so the text can be the same. We say this in Section 1.1 of Basic and Implicit about this:
When the RFC 2119 language applies to the behavior of OpenID Providers, it is in this specification for explanatory value to help Client implementers understand the expected behavior of OpenID Providers.
This concludes my final reviews.
Thanks for putting in all the time. The specs are improved because of them.
Nat Sakimura (=nat)
Chairman, OpenID Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab