Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resource Registration Document: 'uri' should be an array / examples #270

Open
nynymike opened this Issue Jan 10, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@nynymike
Copy link

nynymike commented Jan 10, 2017

  1. In section 2.1, uri is defined as singular, but it would be useful if an RS could register an array of uri's.
  2. Should the spec say that the use of * as a wildcard is allowed. In a url such as https://example.com/auction/*/edit it may be useful. Regular expressions would be more powerful but a little harder for implementers to support.
  3. None of the examples of resource documents include the uri JSON key... this would really help with the clarity.
@xmlgrrl

This comment has been minimized.

Copy link

xmlgrrl commented Mar 13, 2017

Per UMA telecon 2017-03-09: Now that we separated out issue #277 from this one:
A wildcard character is just another character, so if a singleton URI contains wildcards that are known to have special properties only to the RS, great; we're not crazy about giving the AS special wildcard-processing capabilities, though. (This is sub-issue no. 2 [above].) How much are we getting into the game of allowing the AS to use this to be "something else", such as a discovery service? Eve's idea was that the RS could put in both the URL for – say – "rev 19" of Core and also the soft link URL for the latest rev of Core. The concern is that it could be abused by the RS. Justin makes the argument that "uri" being meant for more than just display (e.g., true resource discovery), and reaching outside the UMA entity ecosystem, it has greater security and privacy consequences than any of the human-displayable stuff. We have consensus on removing the uri field and marking this issue with the extension label.

(On resource description documents, the "uri" property was defined as "OPTIONAL. A URI that provides the network location for the resource being registered. For example, if the resource corresponds to a digital photo, the value of this property could be an HTTP-based URI identifying the location of the photo on the web. The authorization server MAY use this information in various ways, for example, to inform clients about a resource's location as a discovery function. Note: When a client attempts access to a presumptively protected resource without an access token, the resource server needs to ascertain the authorization server and resource identifier associated with that resource without any context to guide it. In practice, this likely means that the URI reference used by the client needs to be unique per resource.")

@xmlgrrl xmlgrrl closed this Mar 13, 2017

@xmlgrrl xmlgrrl removed the V2.0 label Mar 15, 2017

@xmlgrrl xmlgrrl reopened this Mar 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.