Monday, April 21, 2008
Steve does it again...
If you read this blog you get to watch me struggle to articulate some of the important subtleties of working with XRI, XRDS and XDI. Check out this article written by ooTao CTO Steven.Churchill which show very clearly who the real brains of this operation is.
Wednesday, April 16, 2008
More on Claims and XRDS
I was recently contacted by Bob Wyman in regard to an earlier post of mine... the first question was:
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?
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?
Tuesday, April 15, 2008
XRDS patterns
Talking with John Bradley yesterday we got into some best practice ideas for XRDS usage. These probably need to me formalized somewhere other than my blog as I think they are important, but here's a first brain dump for you...
1) More abstraction in our Service End Points (SEPs) - Right now we have a tendency to put a uri in the uri element of the SEP. The problem with this is that if the service provider changes their coordinates (or any other detail about their service) they have to change all of their customers SEPs. What we probably want to do is in any given individual's XRDS is provide a pointer to the Service Provider.... Jane uses @xyz for this service.... @xyz is then dereferenced for the access details. If @xyz makes any changes to their service they only have to change the SEP at the @xyz XRDS.
In MOST cases this can be achieved by using an Service Level Ref. In MOST cases the Canonical ID of the XRD that contains the final SEP is actually irrelevant so having many SEPs Ref to the providers' SEP works fine. In cases where the CID does matter (like in an AuthN service) we have to do something else.. An XRI in the URI element would do the trick but that is going to have to be handled by the application as the resolution client will not ''automatically" dereference the xri. However, all the app will have to do is make another call to the resolver while remembering the CID from the first resolution call.
2) XRDS Level Chaching - There are several SEPs that we are defining that, in their simplest uses, only expose a single piece of information. Examples of these are the 'Key Service' where in most cases you simply want the current public key associated with the identifier, or the STS service, where you are simply looking for an assertion of who is the issuer of mCards for this xri. In these cases it is burdensome, especially if we add the abstraction I proposed above, to have to resolve the SEP and then invoke another service to get a single piece of information. We have found that it is convenient in these cases to cache the pertinent piece of information directly in the XRDS. This way you can optimize most discovery and validation interactions. If you find that the cached value is "not what you would expect" (does not provide a public key that matches the signature provided) you can then invoke the described service to find out if the signature used an older, revoked, compromised key.
What do you think?
1) More abstraction in our Service End Points (SEPs) - Right now we have a tendency to put a uri in the uri element of the SEP. The problem with this is that if the service provider changes their coordinates (or any other detail about their service) they have to change all of their customers SEPs. What we probably want to do is in any given individual's XRDS is provide a pointer to the Service Provider.... Jane uses @xyz for this service.... @xyz is then dereferenced for the access details. If @xyz makes any changes to their service they only have to change the SEP at the @xyz XRDS.
In MOST cases this can be achieved by using an Service Level Ref. In MOST cases the Canonical ID of the XRD that contains the final SEP is actually irrelevant so having many SEPs Ref to the providers' SEP works fine. In cases where the CID does matter (like in an AuthN service) we have to do something else.. An XRI in the URI element would do the trick but that is going to have to be handled by the application as the resolution client will not ''automatically" dereference the xri. However, all the app will have to do is make another call to the resolver while remembering the CID from the first resolution call.
2) XRDS Level Chaching - There are several SEPs that we are defining that, in their simplest uses, only expose a single piece of information. Examples of these are the 'Key Service' where in most cases you simply want the current public key associated with the identifier, or the STS service, where you are simply looking for an assertion of who is the issuer of mCards for this xri. In these cases it is burdensome, especially if we add the abstraction I proposed above, to have to resolve the SEP and then invoke another service to get a single piece of information. We have found that it is convenient in these cases to cache the pertinent piece of information directly in the XRDS. This way you can optimize most discovery and validation interactions. If you find that the cached value is "not what you would expect" (does not provide a public key that matches the signature provided) you can then invoke the described service to find out if the signature used an older, revoked, compromised key.
What do you think?
Thursday, April 10, 2008
wow...what a week
Well, RSA is over and we finally get to slow down again.... The last few weeks have been crazed finishing everything that we wanted to get finished to show at RSA. It is VERY cool... the iPage framework is an embodiment and implementation of a lot of the ideas I have been sharing here for the last 3 years. It is real user centric information management. It allows anyone to create a collection of claims from various places and then project them back out into the world progressively and securely. Over the next couple of weeks I will publish more information about iPages and how they work and instructions how to get one of your own.
Watch this space.
Watch this space.
Friday, April 04, 2008
Check it out...
If you're in the SF Bay Area next week, and you happen to be at RSA... You HAVE to come check out the ooTao demo!!
We will be in the OSIS interop room all day Tuesday and Wednesday showing off our stuff... It is well worth stopping by.... You will get to see, what I believe is, the most comprehensive Identity 2.5 mash-up done to-date... And it looks pretty good too.
See you there!
We will be in the OSIS interop room all day Tuesday and Wednesday showing off our stuff... It is well worth stopping by.... You will get to see, what I believe is, the most comprehensive Identity 2.5 mash-up done to-date... And it looks pretty good too.
See you there!
Subscribe to:
Posts (Atom)
