[Openid-specs-ab] openid connect specs review

[Nat Sakimura]

Notes and decisions from July 7, spec call.
This is for the Discovery.

On Fri, Jul 8, 2011 at 4:53 AM, Johnny Bufu <jbufu at janrain.com> wrote:

> Here's the feedback I have for the Discovery draft.
>
> Johnny
>
> ------------------------------**------------------------------**----
> Discovery (draft 01 / July 4, 2011)
>
> 2.  Terminology
>
> Core and OAuth 2.0 terminology is not referenced; this seems intentional,
> since many terms are re-defined, however not as thoroughly. Why isn't
> Discovery referencing them from the other specs?
>

Reference.


>
> Authorization Server is not defined.
>

Reference.


>
> Unique identifiers are mentioned, however the scope within which they
> are/should be unique is not specified.
>

Reference through Client Identifier.


>
> The term Principal is overloaded:
>  "human resource owner" in Terminology
>  "identifier of the target end user" in Provider Discovery
>

Reconcile and Fix.


>
> 3.  Provider Discovery
>
> "Provider discovery is optional, If a RP knows through an out of band
> mechinisim that all identifiers containing particular have the same issuer
> then they can ship this step and procede to Section 4."
>
> It's not clear what is meant by "identifiers containing particular".
>

Delete  "containing particular".


> Typos: mechinisim -> mechanism, ship -> skip, procede -> proceed
>

Accept.


>
> "Provider discovery Simple Web Discovery requires the following information
> to make a discovery request:"
>
> Sentence seems to have two subjects.
>

Accept and Fix.

>
> "What MUST be returned in the response is the Java origin of the Issuer."
>
> What is a Java origin?
>

Fix. Define issuer_id tightly as "Issuers are https URI with host and port.
" and use issuer_id throughout.


> 3.1.  Identifier Normalization
>




>
> The purpose and output of normalization should be made clear here (extract
> principal and host), rather than in the middle of a paragraph in the
> previous section.
>

s/Identifier/User Identifier/

>
> "The user identifier can be one of the following: <list>"
>
> This is underspecified: unclear if the list if complete, or what else can
> qualify as an identifier.
>

Clarify by adding text.


>
> Terminology and Provider Discovery operate with generic identifiers,
> normalization provides a list for what can be a "user" identifier - is this
> intentional?
>

As above.


>
> 3.1.3.  URL
>
> "If the URL does not have a "http" or "https" scheme, the string "https://"
> is prefixed to the URL."
>
> How is it determined that a scheme-less identifier is a URL? Terminology
> defines URL identifiers as either HTTP or HTTPS URIs.
>

As above.


>
> 4.  Provider Configuration Information
>
> It is unclear if what's described in this section is optional or not:
>  "This step is optional."
>

Add "for the relying party."


>  "OpenID providers MUST make available a JSON document
>   at the path .well-known/openid-**configuration."
>
> "Using the Issuer ID discoverd in Section 3"
>
> Issuer ID is not mentioned at all in Section 3.
>

Fix.


>
> typos: discoverd -> discovered, retreved -> retrieved
>

Accept.


>
> 4.2.  Provider Configuration Response
>
> typo: neccicary -> necessary
>
> Accept.


>
> ------------------------------**------------------------------**----
> ______________________________**_________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.**net <Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/**mailman/listinfo/openid-specs-**ab<http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110708/d9764db7/attachment.html>