[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Proposed XRD schema
True there are no libs that do anything with SubjectType.
In the Current XRDS way of things the popup would be described in the
Users XRDS in the <Service> </Service>
Each Service has one or more Types and is extensible to describe any
sort of service.
So having parameters for the size of the popup in the service is not a
problem.
In XRD we are trying to move from having the "User" describe the
service to having the Service describe itself. With the user
effectively restricted to describing the relationships they have with
Services.
So in my XRD I would have:
<XRD>
<Subject> https://ve7jtb.com/jbradley#123 </Subject>
<SubjectType required="false"> http://some.uri.that.denotes.a.person.com
</SubectType>
<Link priority="10">
<Rel> http://specs.openid.net/provider </Rel>
<ResourceType> http://specs.openid.net/auth/2.0/signon </
ResourceType>
<URI priority="10"> https://myopenid.com </URI>
</Link>
</XRD>
Now I probably have the Rel wrong is this going to be a generic
service provider URI for all links?
I am guessing that I still want the openID 2.0 URI in the
ResourceType? Parhaps this should be something more generic to cover
all flavors of openID. It is up to the provider to refine that.
If it were up to me I would point to a generic identifier for the
Service provider. That way the service provider is not locked in to a
particular URI for the service in perpetuity. Indirection here is
good I think.
So my openID Privider publishes an XRD:
<XRD>
<Subject> https://myopenid.com </Subject>
<SubjectType required="false"> http://some.uri.that.denotes.a.openid.provider.com
</SubectType>
<Link priority="10">
<Rel> http://specs.openid.net/service/endpoint </Rel>
<ResourceType> http://specs.openid.net/auth/2.0/signon </
ResourceType>
<URI priority="10"> https://www.myopenid.com/server </URI>
</Link>
</XRD>
The provider may have different endpoints for openID 1.0 vs 2.0 or 2.1
etc Perhaps some support PAPE and others not etc. There may also be
multiple services to provide load-balancing or fault tolerance.
Then the endpoint perhaps has a XRD:
<XRD>
<Subject> https://www.myopenid.com/server </Subject>
<SubjectType required="false"> http://specs.openid.net/auth/2.0/signon
</SubectType>
<SubjectType required="false"> http://spec.openid.net/auth/2.0/ux/popup
</SubectType>
<Link priority="10">
<Rel> http://some.URI.that.indicates.relationsip.is.self.or.sub.service.com
</Rel>
<ResourceType> http://spec.openid.net/auth/2.0/ux/popup </
ResourceType>
<height>500px</height>
<width>450px</width>
</Link>
</XRD>
Trying to work through this example, raises some questions.
Such as:
What are the URI for rel values and how do they relate to the
ResourceTypes at the Link.
Is the relation service provider and type tells the app the sorts of
services the Provider provides.
Can there be more than one <Rel> for a service? The proposed schema
has 0 or more Rel per XRD.
Where is it best to describe the optional services provided by a
restful API. Should that be at the service provider level or at the
service level.
It strikes me that if we are describing things like web services we
need something finer-grained than URI because a single URI can support
multiple services.
So I made up the above self referential link so that there is a
extensible place to put meta-data for them.
In principle I am opposed to conflating meta-data about an optional
API service with the SubjectType.
I know much of this will be up to the application, but where multiple
applications need describing in the same XRD we need to define an
overall entity model between the Personal XRD, the Service Provider
XRD, the Service XRD, and perhaps other types of entities that
discovery will traverse.
Perhaps some applications may want sub service types exposed at
multiple levels. Perhaps the Service Provider has PAPE on one
endpoint but not another. Should the RP have to retrieve all the
endpoint XRD's to discover what one supports PAPE?
The Personal XRD may well list service providers multiple times if
they want to have different priorities on selecting there photo
service vs there openID provider.
As an example Google and Yahoo both theoretically offer photo and
openID services. (Theoretically because they are not necessarily tied
to the same identity and only in some cases discoverable together)
So my XRD might contain four relationships one to Google for open ID
at high priority and one to Yahoo at a lower priority, and the
opposite for photo sharing.
At the person level an app is looking for the service provider with
the highest priority for that applications type. At the Service
provider XRD it is looking for the service with the highest priority
and the appropriate type or types. At the Service the app would be
looking for meta data about the service and its methods and options.
I am interested in other peoples ideas for the discovery flow relating
to URI or XRI for that matter.
=jbradley
On 13-Feb-09, at 3:59 PM, Eran Hammer-Lahav wrote:
> What libraries? :-)
>
> I think it makes sense for us to address the issue of type string
> matchup and to consider the comparison of query and fragment
> components for the purpose of type identification. This is
> regardless if we use the query style or child element style.
>
> EHL
>
>
> On 2/13/09 10:20 AM, "Breno de Medeiros" <breno@google.com> wrote:
>
>
>
> On Fri, Feb 13, 2009 at 10:00 AM, Eran Hammer-Lahav <eran@hueniverse.com
> > wrote:
> This came up for OAuth discovery as well (signature methods,
> parameter methods, etc.). Overall the preference was to mint
> multiple types. However, in this case there are infinite number of
> types because the attributes are numeric, not one out of 3 or 4
> options.
>
> I don't have anything against this proposal but I would suggest an
> alternative for consideration that will avoid the need to extend the
> namespace:
>
> <SubjectType>http://spec.openid.net/auth/2.0/ux/popup?height=500px;width=450px
> </ <http://spec.openid.net/auth/2.0/ux/popup?height=500px;width=450px%3C/
> > SubjectType>
>
> Of course there are many ways to encode parameters into URIs (you
> can put them in the path in a more RESTful way). But this way, the
> type is matched up to the query ('?') and then the rest is
> considered parameters for those who can understand the type.
>
>
> How confident we are that the libraries actually match the type up
> to the end of path only? Might they be doing strict string comparison?
>
>
>
> EHL
>
>
>
> On 2/13/09 9:21 AM, "Dirk Balfanz" <balfanz@google.com <http://balfanz@google.com
> > > wrote:
>
> Hi there,
>
> so we were at the OpenID UX summit the other day and were discussing
> how an OpenID OP can signal to an RP that it supports a "popup-
> style" login flow (example: http://www.puffypoodles.com/popup).
>
> It seems clear that this would belong in the <SubjectType> element
> of the OP endpoint's XRD, something like this:
>
> <SubjectType>https://spec.openid.net/auth/2.0/ux/popup</SubjectType>
> <https://spec.openid.net/auth/2.0/ux/popup%3C/SubjectType%3E>
>
> But what if the information to be conveyed to the RP is not just
> simply the 1-bit information whether or not he extension was
> supported. In this case, the OP might want to tell the RP also what
> size the RP should make the popup. Where would that information go?
>
> One way to make this easier, and allow more structured attributes in
> general, would be to say something like this instead:
>
> <SubjectType uri="https://spec.openid.net/auth/2.0/ux/popup"; />
>
> Now we could do this:
>
> <SubjectType uri="https://spec.openid.net/auth/2.0/ux/popup"; <https://spec.openid.net/auth/2.0/ux/popup%22
> > >
> <height>500px</height>
> <width>450px</width>
> </SubjectType>
>
> What do y'all think?
>
> Dirk.
>
> On Thu, Feb 5, 2009 at 4:26 PM, Eran Hammer-Lahav
> <eran@hueniverse.com <http://eran@hueniverse.com> > wrote:
> Getting a draft out seems to be constantly slipping so below you
> will find
> the proposed schema for XRD 1.0 with most elements explained. Please
> comments, refine, redefine, etc. I will use this thread (and a wiki
> page if
> someone supplements my laziness) and copy suggested text into the
> XRD 1.0
> draft.
>
> EHL
>
> ---
>
> <XRD>
> <Expires> (unchanged)
> <Subject> (was CanonicalID)
> <Alias> (was EquivID)
> <SubectType required> (new)
> <Link priority> (was Service)
> <Rel> (new)
> <ResourceType> (was Type)
> <MediaType>
> <URI priority>
> <TemplateURI priority> (new)
> <LocalID priority>
>
> * <XRD>
>
> The document root element.
>
> * <XRD:Expires>
>
> 0 or 1 per <XRD> element with type xs:dateTime.
>
> The date and time without fractional seconds in UTC "Z" time zone,
> after
> which the XRD descriptor MUST NOT be used. If the XRD was obtained
> via HTTP,
> and the HTTP headers specified an expiry time per section 13.2 of
> [RFC2616],
> the XRD descriptor MUST NOT be used after the earlier of the two
> values
> passed.
>
> * <XRD:Subject>
>
> 0 or 1 per <XRD> with type xs:anyURI and must be an absolute URI.
>
> The canonical identifier. The subject of the XRD which is described
> by the
> other elements.
>
> * <XRD:Alias>
>
> 0 or more per <XRD> with type xs:anyURI and must be an absolute URI.
>
> Provide aliases for the resource described by the XRD. Not allowed
> if no
> <XRD:Subject> is defined.
>
> * <XRD:SubjectType required>
>
> 0 or more per <XRD> with type xs:anyURI.
>
> The <XRD:SubjectType> element declares an attribute associated with
> the
> resource described by the XRD. The value of the <XRD:SubjectType>
> element is
> a URI-formatted attribute-identifier. The meaning of the
> <XRD:SubjectType>
> value is application-specific, and is used by the XRD provider to
> describe
> the resource to consuming applications familiar with the
> attribute-identifier. The attribute-identifier is used in a similar
> manner
> to XML namespace-identifiers.
>
> The <XRD:SubjectType> element supports the 'required' attribute with
> allowed
> values 'true' and 'false'. If not present, the attribute default
> value is
> 'false'. If the 'required' attribute is omitted or explicitly set to
> 'false', a consuming application SHOULD ignore any <XRD:SubjectType>
> with
> values it does not recognize, and interact with the resource based
> on the
> values it does recognize.
>
> However, if the 'required' attribute is set to 'true', a consuming
> application MUST NOT interact with the resource if it does not
> recognize the
> element value. The 'required' attribute is used to indicate to a
> consuming
> application that some predefined knowledge is required in order to
> interact
> with the resource, without which undefined or potentially harmful
> side-effects can occur. The 'required' attribute SHOULD NOT be used
> unless
> such harmful side-effects are likely.
>
> * <XRD:Link priority>
>
> 0 or more per <XRD> and with no text, only child elements.
>
> The <XRD:Link> element declares a relationship between the resource
> described by the XRD and other resources. The <XRD:Link> element
> uses the
> typed-link framework defined by [Link-Header] and carries a similar
> semantic
> meaning as the HTML <LINK> element [HTML-Link], the ATOM <Link>
> element
> [ATOM], and the HTTP Link header [Link-Header]. For example, the Link
> header:
>
> Link: <http://example.com/author>; rel="author"; type="text/plain"
>
> Maps to the following XRD fragment:
>
> <Link>
> <URI>http://example.com/author</URI> <http://example.com/author%3C/URI%3E
> >
> <Rel>author</Rel>
> <MediaType>text/plain</MediaType>
> </Link>
>
> It is important to note that unlike the HTML <LINK> element [HTML-
> Link], the
> ATOM <Link> element [ATOM], and the HTTP Link header [Link-Header],
> the link
> relationships described by the <XRD:Link> element are between the
> resource
> described by the XRD and the linked resources, and not between the XRD
> resource itself.
>
> * <XRD:Link:Rel>
>
> 0 or more per <XRD> with type xs:anyURI.
>
> The <XRD:Link:Rel> element defines the relationship between the
> resource
> described by the XRD and the resources listed using the
> <XRD:Link:URI> and
> <XRD:Link:TemplateURI> elements.
>
> * <XRD:Link:ResourceType>
>
> 0 or more per <XRD> with type xs:anyURI.
>
> The <XRD:Link:ResourceType> element provides hints as to the
> attributes of
> the linked resource(s) identified using the <XRD:Link:URI> or
> <XRD:Link:TemplateURI>.
>
> * <XRD:Link:MediaType>
> * <XRD:Link:URI priority>
> * <XRD:Link:TemplateURI priority>
> * <XRD:Link:LocalID priority>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail. Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]