<br><br><div class="gmail_quote">On Fri, Jul 22, 2011 at 6:31 AM, Casper Biering <span dir="ltr"><<a href="mailto:cb@peercraft.com">cb@peercraft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
I've been looking through the specs and have a number of comments.<br>
<br>
First, I have fixed some seemingly minor naming and formatting issues,<br>
which you can see here:<br>
<a href="https://github.com/Peercraft/OpenID-Specs/compare/master...fixes" target="_blank">https://github.com/Peercraft/OpenID-Specs/compare/master...fixes</a></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
Next, my general review:<br>
<br>
------------------------<br>
<br>
== Discovery (draft 02) ==<br>
<br>
*) Under Terminology, the description for Issuer is: "A verifiable<br>
identifier for the OpenID Provider. An issuer is a HTTPS URL with no<br>
path component."<br>
<br>
Why does the examples show "<a href="https://example.com/auth" target="_blank">https://example.com/auth</a>" as a valid issuer.<br></blockquote><div><br></div><div>Accept. Make it <a href="https://server.example.com/">https://server.example.com/</a> </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
*) It might be a good idea to give some kind of recommendation on how<br>
long (if at all) to cache Provider Discovery and Provider Configuration.<br></blockquote><div><br></div><div>Discuss: </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
== Dynamic Client Registration (draft 04) ==<br></blockquote><div><br></div><div>John: Please make a disposition. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
*) What is js_origin_url used for? Does any examples exist?<br>
<br>
*) In some places, it would be nice for the OP to redirect the user to<br>
the RP. So a having a "application_url" is to be prefered.<br>
<br>
== User Info (draft 06) ==<br></blockquote><div><br></div><div>Breno or Mike: Please make disposition.  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
*) Phone_number should be changed to phone (to match email, rather than<br>
email_address).<br>
<br>
*) Verification claims are equally applicable to phone and address as to<br>
email. Hence a rename from the attribute "verified" to "email_verified"<br>
and the addition of phone_verified and address_verified would be<br>
logical.<br>
<br>
*) As in particular email addresses and phone numbers are often<br>
shortlived, a boolean verification attribute will not persuade most RP's<br>
to omit their own verification process. Instead the use of a datestamp<br>
is proposed.<br>
<br>
(Also most IDP's will probably have a general policy of either verifying<br>
or not verifying emails, so an RP's basic trust in the email addresses<br>
provided by an IDP would rather be a trust framework / policy issue)<br>
<br>
*) As SMS has become a predominant way for RP's to contact customers by<br>
phone, a phone number by itself is rather worthless. It is proposed to<br>
add an attribute phone_support where the value could be a comma<br>
separated string containing one or more of the substrings "voice",<br>
"sms", and "fax".<br>
<br>
*) Framework spec (chapter 8.3) mentions request verification of the<br>
signature in a JWT for UserInfo endpoint, but the userinfo spec does not<br>
cover it.<br>
<br>
*) Why is id_token_audience not placed inside the OpenID Request Object,<br>
as a submember of id_token?<br>
<br>
== HTTP Redirect Binding (draft 04) ==<br>
<br>
*) Remove artifact term (including Core and Framework)<br></blockquote><div><br></div><div>Accept</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
*) Chapter 3.1.1 Both this spec and core says that redirect_uri is<br>
required in the Authorization Request, but the OAuth specs says its<br>
optional, if it is optained out-of-band (which in our case can be client<br>
registration).<br></blockquote><div><br></div><div>Discuss: From interoperability point of view, it may be good to reduce the variability. That is why the current one makes it MUST. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
*) Chapter 3.1.1: It would be nice if all the parameters had references<br>
to where is it defined, especially as Nat recommends reading the<br>
http-redirect spec first.<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
*) Chapter 3.1.1.2 and 3.1.1.3 should be moved to Framework, to make<br>
http-redirect spec more simple.<br></blockquote><div><br></div><div>Accept. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
*) Chapter 3.1.6.1 should contain a description of user_id and domain.<br></blockquote><div><br></div><div>Discuss: user_id and domain may be removed from the example. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
*) Chapter 3.1.7.1, 3.1.8 and 3.1.8.1 should be removed, since its<br>
covered in user-info spec.<br></blockquote><div><br></div><div>Reject: Relevant portion of UserInfo should be included so that Lite does not have to reference anything in the spec suite. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
== Core (draft 10) ==<br>
<br>
*) With all the examples in core, it looks like its a shortcut version<br>
of http-redirect. I suggest removing all examples, to make it less<br>
confusing.<br></blockquote><div><br></div><div>Discuss: Agree that they tend to be HTTP specific. Could the example be made completely protocol agnostic? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
*) The prompt=consent param in the Authorization Request, what is the<br>
current use-case for it? We were thinking of using it for redirecting<br>
the user to our "which (additional) info do you want to disclose to this<br>
RP?"-page.<br></blockquote><div><br></div><div>Discuss: That is one use case. There are other cases that you want to obtain re-consent to refresh the consent time. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
== Common ==<br>
<br>
*) From a specs writer point of view I understand why core and<br>
http-redirect are separated, but as an implementer, its very confusing.<br>
As mentioned above, removal of the http-redirect examples might help.<br></blockquote><div><br></div><div>Lite will not have any reference to Core. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
*) There are mixed use of hostnames (and urls) throughout the examples:<br>
<a href="http://client.example.com" target="_blank">client.example.com</a><br>
<a href="http://rp.example.com" target="_blank">rp.example.com</a><br>
<a href="http://op.example.com" target="_blank">op.example.com</a><br>
<a href="http://example.com" target="_blank">example.com</a><br>
<a href="http://server.example.com" target="_blank">server.example.com</a><br>
<a href="http://example.net" target="_blank">example.net</a><br>
<a href="http://client.com" target="_blank">client.com</a><br>
A systematic alignment of example URLs would make it easier for<br>
newcomers to read the specs.<br></blockquote><div><br></div><div>Accept: Standardize on </div><div><br></div><div><a href="http://client.example.com">client.example.com</a></div><div><a href="http://server.example.com">server.example.com</a></div>
<div><br></div><div>although in distributed claims scenario, we may use </div><div><br></div><div><a href="http://sever.example.net">sever.example.net</a> etc. as necessary. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
== Session Management (draft 02) ==<br></blockquote><div><br></div><div>Edmund: Please make the disposition. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<br>
*) A rewrite as proposed by Breno seems a good idea.<br>
<br>
*) Chapter 3.2.1 & 3.2.2 & 3.2.3: Does not specify the error messages<br>
and flow, if the action could not be completed.<br>
<br>
*) Would be nice if the spec included single logout.<br>
<br>
== Framework (draft 04) ==<br>
<br>
*) Where is the documentation for ID token JSON response from the Token<br>
Endpoint? I can only find an example in Framework chapter 5, and Session<br>
chapter 3.2.2.<br></blockquote><div><br></div><div>Accept: Write it in Message.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
----------------------<br>
<br>
I hope you will find some of this input useful.<br>
<br>
--<br>
Best Regards<br>
<br>
Casper Biering<br>
<a href="mailto:cb@peercraft.com">cb@peercraft.com</a><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div><br>