Hi Thomas,
Here is some initial feedback.
Introduction paragraph 2:
Remove duplicate "with": "the OpenID Provider (OP) component is a
specialized version of an OAuth authorization server that brokers
availability of user attributes by dealing *with with* an ecosystem of
attribute providers (APs)."
Section 1.2 Terminology:
This is more of a comment for the UMA WG in general: "scope type" is an
unfortunate term (which appears in the UMA core draft [1] as well - if
memory serves the term used to be just "scope" but I couldn't find a diff
reference for when that changed). Including "type" in the term makes it
sound like it refers to a class or kind of scope, which doesn't seem to be
what you mean. I understand that "scope" cannot be used since it is
already reserved by OAuth, but perhaps a better synonym could be found and
used instead?
2. Resource set registration
2nd sentence reads oddly. Change from "For any of the resource owner's
sets of resources this authorization server needs to be aware of, the
resource server MUST register these resource setsŠ" to "If this
authorization server needs to be aware of any of the resource sets, the
resource server MUST register those resource setsŠ"
2.2 Resource set descriptions
"scopes" and to refer to sets of "scope type"s and "type" to refer to the
class/kind of resource set this is add to the argument above that "scope
type" is a misleading term.
2.3 Resource set registration API
I don't understand what this sentence means: "Without a specific resource
set identifier path component, the URI applies to the set of resource set
descriptions already registered." Can you clarify?
The {rsreguri} URI component is defined but never used. It looks like all
of the "/resource_set" URIs should be prefaced with this component
throughout the following sections?
[1] https://datatracker.ietf.org/doc/draft-hardjono-oauth-umacore/
--
Amanda Anganes
Info Sys Engineer, G061
The MITRE Corporation
781-271-3103
aanga...@mitre.org
On 12/27/12 2:24 PM, "Thomas Hardjono" <hardj...@mit.edu> wrote:
>Folks,
>
>The OAuth 2.0 Resource Set Registration draft is essentially a generic
>first phase of the User Managed Access (UMA) profile of OAuth2.0. This
>allows the RO to "register" (make known) to the AS the resources he/she
>wishes to share.
>
>Looking forward to comments/feedback.
>
>/thomas/
>
>__________________________________________
>
>
>-----Original Message-----
>From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org]
>Sent: Thursday, December 27, 2012 2:07 PM
>To: Thomas Hardjono
>Subject: New Version Notification for
>draft-hardjono-oauth-resource-reg-00.txt
>
>
>A new version of I-D, draft-hardjono-oauth-resource-reg-00.txt
>has been successfully submitted by Thomas Hardjono and posted to the IETF
>repository.
>
>Filename: draft-hardjono-oauth-resource-reg
>Revision: 00
>Title: OAuth 2.0 Resource Set Registration
>Creation date: 2012-12-27
>WG ID: Individual Submission
>Number of pages: 19
>URL:
>http://www.ietf.org/internet-drafts/draft-hardjono-oauth-resource-reg-00.t
>xt
>Status:
>http://datatracker.ietf.org/doc/draft-hardjono-oauth-resource-reg
>Htmlized:
>http://tools.ietf.org/html/draft-hardjono-oauth-resource-reg-00
>
>
>Abstract:
> This specification defines a resource set registration mechanism
> between an OAuth 2.0 authorization server and resource server. The
> resource server registers information about the semantics and
> discovery properties of its resources with the authorization server.
>
>
>
>
>The IETF Secretariat
>
>_______________________________________________
>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
