Some time ago, you wrote:I had to respond that I never did write that spec but offered to consider his use-cases if Bob thought it would be useful. He sent me these use cases:
SEPs in XRDS must be considered self asserted
claims and as such should not be trusted on their
face. Service Providers should publish the
mechanisms by which SEP claims should be validated
to be about a specific subject (authenticated
identifier). (ooo… I feel another spec coming).
Did that spec ever get written?
Well, there are two kinds of things that I would like to be able to validate. The generic issue here is one of XRDS spam...And I responded like this.... NOTE: if you manage to read the whole thing AND find the intentional mistake... you win a prize (at least you may be entered into a random drawing and have your name honorably mentioned by me to my family over diner one night).
1. If I'm hosting a blog for someone and there is an XRDS file with a SEP that forwards to that blog, how do I assure a third party that the XRDS file belongs to the person for whom I am providing blog hosting?
2. If an XRDS file contains a link to some descriptive service (perhaps an XML file that describes the business and claims that the subject is a "Pizza Parlor"), how do I make the assertion that I know the subject to be, in fact, a Pizza Parlor?
I SAID: -
First I have to give the disclaimer.... these ideas are just our thinking on the subject, we do not represent the XRI TC or any other body, blah, blah, you get the idea...
John Bradley and I spent a good couple of hours talking this through and have come up with 2 answers for you... One is the practical, how you should probably do it today kind of answer and the other is the 'doing it right' answer, which would mean taking on a lot more of our abstract thinking and an XDI server. The 'simple' answer still has problems that I will highlight...
Use Case 1) How to assert at an arbitrary http endpoint (web page, blog) a relationship with a specific XRDS.
The 'simple' solution is that the http endpoint support YADIS discovery to 'get' the desired XRDS. The claim in this case would be validated by reseprocity. The XRDS returned by YADIS discovery MUST have EITHER an 'EquivID' or a 'CanonicalEquivID' that is the URI of the original endpoint.
The one problem with this 'simple' approach is if you as the service provider or the end user actually have the ability to put the EquivID element into the users' XRDS. If, for example, this was Blogger blogs and Blogger OpenID 2.0 XRDSs then you would have the ability to edit the XRDS and the blog to create the reciprocal relationship. If the use case is broader than that you need to fall back on other mechanisms for the 'other end' of the relationship to be established. The options there would be:
a) tell the user to 'go edit their XRDS' - and wish them luck :-)
b) Use XRDSPP (XRDS Provisioning Protocol) - which is partially specified here: http://dev.inames.net/wiki/XRDSP_Spec and partially specified here: http://xpp.seedwiki.com/wiki/xpp/specs and not yet implemented or deployed anywhere that I know of. (although it is the 'next thing on our list' as MANY use cases depend on its existence)
Use Case 2) How to assert a third party claim in an XRDS.
I'm not SURE that I have understood your use case 100% so I will be verbose about the problem that I am solving in case it isn't the question you asked...
What is not clear to me from your question is what an RP would be looking for in the XRDS .... Would they be looking for "what does Service XYZ know about this entity" OR would they be looking for "what claims are available about this entity" OR would they be looking for "Is the entity represented by this XRDS a Pizza Parlor?"
If the question is: What does 'this service that I trust' know about the entity represented by this XRDS then the flow would be:
1) RP looks for the CanonicalID associated with the Authentication Service SEP that they use to authenticate this entity (if they interact with the entity using OpenID then they need the CID of the XRD that contains the OpenID SEP, if they have a 'signed document' from the entity they would use the CID of the XRD that contains 'KeyService' SEP (the place you get the public key)) .
2) The RP presumably knows the URI of 'this service that I trust' so they simply parse the CID, AND THE SERVICE TYPE, to the 'trusted service' and the trusted service returns 'claims' about the specified entity. SAML would be an obvious choice for expressing the claims but one could use any format one chooses.
If the question is: What claims are available about the entity represented by this XRDS then flow flow would be:
1) Perform Service Discovery for a 'Claims' service (not yet formalized but we could make one up on the fly if we needed to).
2) Perform Service Discovery for the AuthN service (like above) to get a 'Key' CanonicalID.
3) Ask the claims service (assuming that the claims service has a well known API) about the entity by passing in the CID and the AuthN Service Type.
4) Get back a list of claims... The claims should always be verbose and specific... not: 'this guy is over 18' .... but "Claim service A says - the guy who on this date and time had the credentials for the OpenID Service for CID =!abcabc is over 18". As per my blog post yesterday about "XRDS Caching" this claim could be cached in the SEP to optimize this interaction. Depending on how the claim is retrieved, from cache or from the service itself will dictate the level of crypto verification you might want to apply to the claim.
If the question is: Are you a Pizza Parlor then the flow would be...
1) Get the XRDS for the CID (no service selection) and iterate over the XRD level Type elements to see if anyone has claimed that this is a Pizza Parlor. The Type element of the XRD is an XRI that might me in the 'self issued' form.... "xri://+pizza.parlor" or it may be in the 'asserted' form... xri://@google*(+pizza.parlor). In the assert form, if you decide to trust the asserter, you can validate the claim by the same means as answering the first question in this use-case where google just became your 'trusted service'.
AND THAT"S THE END OF THE SIMPLE ANSWER :-)
So in fact the 'how it SHOULD be done' (according to Andy Dale) answer is a lot simpler if you can overcome one pre-requisite..... First install your XDI server... the rest is easy, really... if you want to know I'll write up how that would work.
Did you spot the mistake?
6 comments:
In use case 1: I can understand why the EquivID would need to be in the XRDS returned by the Yadis discover process at the blog hosting site (which is being used to verify the claim in the original XRDS file) since that Yadis system would being saying: "I think this XRDS file is equivalent to the one you asked about...." But I don't understand why an EquivID would need to be in the XRDS file that is being verified. Or, perhaps I misunderstood what you wrote...
bob wyman
My understanding of this is that there is only 1 XRDS in play here. The 'blog' wants to specify that the 'owner' of this blog is also the 'owner' of 'this' XRDS. The XRDS that is returned by yadis discovery is the same as the one returned by yadis discovery of the same persons OpenID. In the OpenID case the user 'proves' ownership by providing credentials to the OP. In the blog case the owner 'proves' control of the XRDS by editing the XRDS to include a pointer to the blog.
Does that make sense?
If there is only one XRDS file in play and "proofs" are recorded as edits to that single file, then it seems that anyone who has write access to the file can forge any proofs.
As a reader of the XRDS file, I would have no idea who had authored which lines in the file. Thus, I wouldn't be able to rely on any statements made within it.
bob wyman
Sorry, I new I wasn't being clear even as I posted that last comment...
There is only one XRDS. The 'owner' of the XRDS and their IDP are the ONLY entities able to edit that XRDS. The individual better trust his IDP or he's got deeper problems.
The 'poof' is based on a statement in the XRDS that any given uri (xri,url) is 'about me'. That statement needs to be put in the XRDS once and acts as a proof that 'someone with the credentials to edit this XRDS has stated this relationship'
The blog is basically just pointing at that proof in the persons XRDS. We explored a bunch of different ways for a 'blog' (random web page) to 'point' at an XRDS... should it use a rel tag? a microformat? a microID? etc... We realized that there is already a spec for 'discovering' an XRDS from a uri... yadis. That doesn't mean that the uri is authoritative for the XRDS just that it is pointing at it.
Am I helping yet?
> Am I helping yet?
Errr.. Not really...
Let me restate the problem:
Given:
a) I run a blog hosting service and host a blog for =bobwyman
b) One or more XRDS files exist which point to =bobwyman's blog. Only one of these XRDS files is "owned" by =bobwyman.
c) Pointing to =bobwyman's blog from an XRDS file is, in this case, considered the equivalent of claiming a binding between the blog and the owner of the XRDS file.
Problem:
When asked, I want to be able to say about an XRDS file that: "This XRDS file, which points to =bobwyman's blog, is, or is not, known to me to be owned by the person for whom I believe I am hosting the blog. (i.e. =bobwyman)"
What I am trying to do here is provide third-party verification of assertions in XRDS files.
bob wyman
You control a URL, in this case a blog.... You want to assert a relationship with an XRDS. You need to provide a way for a 3rd party to 'discover' or 'request' that XRDS ownership assertion from your url... right?
You could:
1) Use a rel tag in the blog page
2) use some micro-format on the page
3) embed SAML in your page
BUT
I think there is a well defined way to find an XRDS from a url... yadis.
The fact that yadis discovery on the a URL resolves to an XRDS IS a claim by the service provider of 'ownership' or 'association'.
A 3rd party who wants to ask the blog if there is an associated XRDS for this blog (or blog owner) simply initiates yadis discovery on the blog url... If they get back an XRDS... The answer is 'Yes, this one' if no XRDS is discovered then the answer is no.
Post a Comment