[OpenID] general Digest, Vol 28, Issue 204

[John Bradley]

Peter,

You could define a new service for your ordered list and use the  
priority attribute on the URI element to order them.

Using HXRI a browser would always be redirected to the URI with the  
highest priority.  If a smart client retrieves the XRDS it can do as  
it likes with the ordered list of URI elements.

It's just XML so you need the priority attribute to make the list  
ordered rather than selected randomly if they are all at the same  
priority.   Of corse if you want simple load balancing you can make  
them all the same priority.

=jbradley

On 29-Dec-08, at 6:45 PM, Peter Williams wrote:

> That was very useful. Thanks. Its puts a wholly new perspective on  
> XDI. Sparql-like -  with the HXRI security model, a resolver query  
> model, and signed tokens that link the set of XRDs in the closure set.
>
> Ignore my previous jibberish. It was attempting to make sense of an  
> old document that was almost imprehensible, and apply it to openid  
> discovery. Basically, I just want the XRDS that comes back to have a  
> Service element that has a list of blog site synonyms (in addition  
> to OP endpoints, delegations etc). Viewing that synonym list as an  
> ordered list, I wanted my consumer to check that the set of 30x  
> redirects my consumer had just gone through (to get to the XRDS) was  
> “consistent” with the order of the synonym list in the XRDS.
>
> It’s not clear that the XDI forwarding service would even preserve  
> the original order of the synonyms, however.
>
> From: general-bounces at openid.net [mailto:general-bounces at openid.net]  
> On Behalf Of John Bradley
> Sent: Monday, December 29, 2008 10:52 AM
> To: general at openid.net
> Subject: Re: [OpenID] general Digest, Vol 28, Issue 204
>
> Peter,
>
> XDI is a RDF data service that uses XRI for addressing data.  Think  
> SPARQL with security.
>
> XRI proxy servers will select a sep for backwards compatibility with  
> existing browsers and give you a 302 redirect to the URI element of  
> the SEP.  This is based on standard XRI service selection criteria.
>
> We will be changing the 302 to a 303 in the next version of the spec  
> to make it more AWWW friendly.
>
> You may want to look at my XRDS =jbradley for some creative things  
> using content negotiation and HXRI proxys.
>
> It is possible to run your own XRI authority server to serve the  
> XRDS documents as a community registry.
>
> In the next version of XRI we intend to make it easier for people to  
> run there own XRI registries using a URI cross ref for the first  
> subsegment.
>
> iBrokers currently offer a service called a forwarding service.   
> This is separate from using the XRDS to do the forwarding.  The  
> forwarding service is normally configured as the default service for  
> queries with a path component.
>
> The HXRI proxy uses URI construction to create a new URI that is  
> passed to the forwarding service.  The forwarding service then  
> performs a redirect.   The forwarding service itself is not a part  
> of XRI, rather it is a value add provided by iBrokers.
>
> None of this redirection applies to openID discovery directly.
>
> Currently the URI rewriting rules are quite simple like appending  
> the Query XRI etc.
>
> The TC is looking at expanding URI construction rules in the new XRD  
> spec.
>
> I am not quite certain what you are trying to achieve,  but I  
> suspect that XRI  is probably not the best thing to use as a URI  
> rewriting and forwarding service.  That really was only intended as  
> a backwards compatibility feature for existing web browsers.
>
> Feel free to email me directly.
>
> Regards
> =jbradley
>
>
>
> On 29-Dec-08, at 3:11 PM, general-request at openid.net wrote:
>
>
> Message: 1
> Date: Mon, 29 Dec 2008 09:31:48 -0800
> From: Peter Williams <pwilliams at rapattoni.com>
> Subject: Re: [OpenID] XDI cross-references
> To: "general at openid.net" <general at openid.net>
> Message-ID:
>               <BFBC0F17A99938458360C863B716FE463981A70320 at simmbox01.rapnt.com 
> >
> Content-Type: text/plain; charset="us-ascii"
>
> Concerning line ~219 http://iss.xdi.org/moin.cgi/ForwardingService?action=AttachFile&do=get&target=iss-forwarding-v1.0-wd-03.pdf
>
>
> Is there anywhere I can use an XDI-like service...to try out its  
> integration with actual openid discovery clients (pbwiki, plaxo,  
> blogspot, etc)?
>
>
> Am I right to think that the scheme is saying that if I type in an  
> HXRI invoking the forwarding service, a 3xx https response may come  
> back - whose URL form _can_ be another HXRI ...calling upon another  
> XDI-like forwarding network? That pattern of double discovery may be  
> viable for realty: use an i-broker governed forwarding service to  
> locate a private forwarding service that is not governed  by i- 
> broker vendor associations. Some Realty MLSs would run their own XRI  
> forwarding service, and others would want to use the private-label  
> services of Neustar, etc.
>
> Ok less theory, more practice! We have a need to let query-based  
> openid discovery agents use their rule-rewriting expressions to  
> produce a websso-switch invocation URL of the form:
>
>
> http://swmrsso.rapmlsstg.com/sp/startSSO.ping?PartnerIdpId=rapattoni:mlsstgswmichigan:entityId
>
>
>
> If I was to use i-names as the entity name for the openid entity in  
> PartnerIdpId (=example/seattle/sightseeing), I can see the  
> forwarding service producing for me, given the input https://xri.net/=example.personal.nickname/(+forwarding)
>
>
>
> http://swmrsso.rapmlsstg.com/sp/startSSO.ping?PartnerIdpId=%3dexample%2fseattle%2fsightseeing
>
>
>
> is there an example forwarding service that is really capable of  
> this (including the url encoding)?
>
> (No...I cannot change the required form of the target URL, its set  
> by the websso-switch vendor).
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081229/2c13b4d3/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2486 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20081229/2c13b4d3/attachment-0002.bin>