[XRI] Identifiers and forms on the wire

Stuart,

I am an identity metasystem guy, so I tend to approach this from that  
perspective.

Lets consider openID identifiers that I have.
1. https://thread-safe.com   My costs are $10/year to ICANN/DNS  
registrar and $399/year to Verisign for a SSL Cert. (I own and control  
my ID and can delegate authenticaton to a provider of my choice or can  
run my own openID provider.
2. http://ve7jtb.myvidoop.com My costs are the advertising I receive.   
HTTPS is not supported so security is questionable at best.  I cant  
move or really control the ID.
3. xri://=jbradley or https://xri.net/=jbradley My costs $12/year  
includes an openID provider service.  I own and control this  
identifier.  I can move it between providers( xri://=ve7jtb is also  
configured as an alias).
4. xri://@id*五里霧中 or https://xri.net/@id*五里霧中  My costs  
$0/year  This is a community iname I cant transfer outside of the @id  
community.   I do also have an alias to the openID https://xri.net/@id*gorimuchuu 
  for sites that don't work with IRI.

No I don't really pay VariSign $399/year for my cert though they think  
I should.
openID is not secure if the meta-data is not retrieved over SSL  I  
have a number of blog posts on the topic http://thread-safe.livejournal.com/13200.html 
.

Given that CURL is the library most used by openID Reliant Partys the  
the libcurl certificate bundle determines the Certs useful for  
securing openIDs.

The XRI resolution through a native client lib like openXRI or through  
a HXRI proxy should always default to SSL or SSL+SAML resolution.

So lets consider wire formats for openID.

The first step of openID is to discover the metadata for the identifier.

If the identifier is a URL then the openID Reliant Party (RP) preforms  
a get or head on the URL with an accept header of application/xrds+xml
http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cs01/xri-resolution-V2.0-cs-01.html 
   Section 6 Discovering an XRDS Document from an HTTP(S) URI

An XRDS document is returned this contains endpoints for openID 1.1  
and or openID 2.0,  There are fallbacks to rel links etc to support  
older openID providers.

If the identifier is a HXRI the RP will preform exactly the same steps  
it would with any URL.

The IRI form of a HXRI is a bit problematic at the moment.  I only  
know of one RP library that properly attempts to encode a IRI as a  
URL.  It is currently considered out of scope of the openID 2.0 spec.

If the identifier is a XRI enterd in the form @id*五里霧中  or  
xri://@id*五里霧中 the RP will first normalize this to URI form  
xri://@id*%E4%BA%94%E9%87%8C%E9%9C%A7%E4%B8%AD

Discovery is then done one of two ways
1. By converting the URI to a HXRI https://xri.net/@id*%E4%BA%94%E9%87%8C%E9%9C%A7%E4%B8%AD/?query&_xrd_r=application/xrd+xml&sep=true&https=true&_xrd_t=http://specs.openid.net/auth/2.0
2. Via native resolution through a library like openXRI.  If openXRI  
is resolving over a HTTP binding,  Individual requests for each  
authority subsegment XRD are formatted into https:// URLs.   There can  
be other protocol bindings for resolution.

Its a detailed spec I don't want to reiterate the whole thing.

If a http binding is used for the resolver or HXRI is used then the  
wire format is URL

Internally to an application a IRI/URI form may be used as translating  
the users input to a URL.

There is no goal to replace URL identifiers in openID with iNames.

There are a number of options or iNames not all require payment.

Not all iNames require any connection to GRS.
Two forms od iNames/XRI are rooted in DNS rather than GRS.
1. xri://beoing.com/somepath    This is an IRI authority XRI
2. xri://(http://boeing.com)*jbradley     This is a URI cross reference.

As part of our discussion on HXRI forms we are looking at ways to make  
non GRS XRIs easier for people to use.

If XRI could only be used through GRS I would not personally support  
the spec.

I hope this answers some questions for you.  Is there some place that  
people think we are using an improper wire format?

Please let me know if that is the case so we can explore that in detail.


Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中


On 19-Jul-08, at 3:54 AM, Stuart Williams wrote:

> Hello John,
>>
>>
>> Is there some thought that only URLs should be used as user  
>> identifiers for application purposes?
> I'd described it as a pro-URI bias - that shouldn't be a surprise. I  
> also scoped my comment in terms of languge/format definitons -  
> rather than UI artefacts and login forms.
>
> Lets say, that my email address, skw@hp.com is used as a user  
> identifier for me in some system.
>
> I could define a userId element in some new format and say that its  
> content must be an email address thus:
>
>   <userID>skw@hp.com</userID>
>
> or I could leave the definition in the format spec more open and say  
> that element content must be a URI
>
>   <userID>mailto:skw@hp.com</userID>
>
> I believe that the TAG bias is toward the latter.
>> If I want to log into a application what identifiers are Good vs Bad?
>>
>> 1. jbradley
>> 2. jbradley@wingaa.com
>> 3. =jbradley
>> 4. xri://=jbradley
>> 5. http://xri.net/=jbradley
>> 6. =!BF81.FD97.C81B.B4E5
>> 7. thread-safe.net
>> 8. http://thread-safe.net
>> 9. VE7JTB
>> 10. 703-650-0389
>>
>> These are all identifiers that I use to gain accesses to  
>> resources.  Is there a desire to restrict the acceptable form of  
>> input for an openID?
> I guess that was the question I was asking you... is there a desire  
> to promote the i-name/i-number based identifiers in formats to the  
> exclusion of equivalent URI forms. Requiring folks to have to  
> purchase/rent an i-name (at $12 per personal -name per yeat [2]) to  
> use, say Oauth or OpenID [and I am not saying that *is* the case,  
> but I believe that that peception exists] would be unaccceptable to  
> many. FWIW, and I'm sure that you can correct me, I expect that the  
> relevant specs.will allow more general URI forms of identifier, and  
> may even require URI forms of XRI in fields that are exchanged 'on  
> the wire'.
>
> [2] http://2idi.com/register
>
> To answer your question above: wrt to a closed system without shared  
> identities then whatever you like. Where identities are shared, the  
> identity components in message that cross the wire should all be URIs.
>
>> If we don't use a URI scheme then obviously the xri:// form that is  
>> currently valid would need to be deprecated.
> The above is orthogonal to the scheme question =jbradley is not a URI.
>> If I enter =jbradley into an openID RP and the RP normalizes  that  
>> to http://xri.net/=jbradley in the same way that if I enter thread- 
>> safe.net it will normalize that to http://thread-safe.net,  is that  
>> a problem?
> RP??
>
> I think so, certainly I wouldn't have problem with that - and I  
> wouldn't have a problem with xri://=jbradley either were it  
> successfull registered as a xri: scheme or were it generally  
> acceptable as a URI scheme and on track for registration (which I  
> know was an intent that we may have disrupted).
>
>> If  OpenID were to adopt CURIE as you suggest, then if we define:
>> xmlns:xri="http://xri.net/"
>>
>> That would allow a identifier such as  xri:=jbradley to be entered  
>> and become http://xri.net/=jbradley  ?
> Again, I was not talking in terms of what a user enters in a UI, but  
> what crosses the wire on a message.
>
> UI Fields -> URI -> full or abbreviated URI in a message. I was  
> offering CURIEs as an abbreviation mechanism that could be adopted  
> in message formats, though equally (IMO) base+rel URI will also  
> serve in many cases.
>>
>> I am new to CURIE so the answer is probably obvious to others.
>>
>> If that is the idea then perhaps CURIE is an option.
> I only mention them because, at least in the hypertext community  
> there is a lot of negative reaction at the prospect of authors  
> having to correctly and repeadly write lengthy URI that differ only  
> in a few trailling characters... CURIEs is an approach to addressing  
> that problem from the hypertext community.
>
> I would not expect end users typing credentials into a login form to  
> have to care or be aware of it.
>>
>> Regards
>> John Bradley
>> OASIS IDTRUST-SC
>> http://xri.net/=jbradley
>> 五里霧中
>
> Stuart
> --
>