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

[nynymike]

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]

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.")