OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xri-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: XRI Resolution 2.0 CD 2: Request to enable <Type> element at the<XRD> level

XRDS provides a simple format for service discovery. While services described by the document can be assigned multiple types, there is no simple way to provide a similar type context for a group of services, which is needed for two use cases being developed at this time:

XRDS-Simple - a subset of XRDS used for applications where only a small set of features is needed (as seen in the OpenID 2.0 use case) or development resources are limited and parsing of the full XRDS format is prohibitive. XRDS-Simple will be fully compatible with XRDS as specified by XRI Resolution 2.0, but parser designed for XRDS-Simple need a way to tell if an input document adheres to the stricter format, or if attempting to parse the document may lead to incorrect discovery (due to lack of support for elements such as Ref and Redirect). To indicate that an XRD element, among many possible XRD elements in a single XRDS document, obeys the XRDS-Simple format, a Type element is needed at the XRD level.

OAuth Discovery - OAuth defines a set of service endpoint used to allow a consumer access to a user's resources on a service provider. The discovery protocol allows automation of the process and attempts to bring OAuth to the same level of automation currently available in HTTP Basic Auth. OAuth discovery requires that XRD elements used as part of the process must obey certain rules, and must include a set of Service elements. When parsing such documents, parsers are required to validate XRD elements by ensuring they contain valid OAuth services. To indicate an XRD is to be used as part of OAuth Discovery, a Type element at the XRD level is needed.

In both cases, this can be accomplished using a workaround, by including a Service element with only Type childred. Parsers will look for such element with no URI or Path children and assume it is there to describe the XRD as opposed to the Service it resides in (since it is empty otherwise). While this will work, it is an awkward solution and is somewhat of an abuse of the specification.

Therefore I would like to request that the specification explicitly allow using the Type element at the XRD level with the same meaning and syntax as it is allowed within the Service element.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]