| RE: [higgins-dev] IdAS Registry and XRI Ad hoc conf call #2 |
|
The first endpoint in your SAML example is identified by "xri://+i-service*(+authn)*(+saml)*($v*1.0)", right?
I assume resolution for this example must work because there would be no other saml authn or saml metadata SEPs in the XRDS that has been resolved to at this point (there's nothing else in this example XRI which indicates any previous resolution, so I assume the XRI example is somehow only partial)
I'm trying to imagine how Higgins context SEPs might be situated and resolved to in XRDS documents. I had originally thought that a number of Higgins context SEPs could co-exist as sibling <service> elements. I guess it has to do with:
- what we use for resolution (service type, metadata type, path)
- what's placed in those fields.
If we only used the service type, then each service type would be different for each Higgins context SEP. After my initial phone call with Andy and Steve, this was what I was thinking we'd end up doing. Andy suggested formalizing some kind of hierarchical identifier which is why I suggested the type element contain something made up of these components (for example) {Higgins IdAS Context, JNDI, Corporate Directory}. How that is best represented as a URI, I don't know -- maybe (mutating the saml example) something like: "xri://+i-service*(+higginsContext)*(+jndi)*(+corp-dir)"
Jim
>>> "Drummond Reed" <drummond.reed@xxxxxxxxxxxx> 2/22/07 12:52 PM >>> Jim, From everything I know so far (which isn't enough ;-), I think your analysis is correct, and Andy correctly identified that the two-step XRI resolution pattern is the one you need. In the first step, you want a Higgins CID (context identifier) to be resolvable (when represented as an XRI) to an XRDS that describe metadata about that CID. This CID description metadata could then optionally include a second XRI representing a specific set of configuration metadata, which can be resolved to obtain (and cache) a copy of that configuration metadata. The precedent we've seen for this is the use of SAML authentication for identifies represented with XRIs. The original XRI, say =drummond, is resolved to an XRDS document with a SAML authentication service endpoint (itself identified with the XRI "xri://+i-service*(+metadata)*(+saml)*($v*1.0)" as documented at http://iss.xdi.org/moin.cgi/IserviceEndpointDefinitions). This service endpoint block in the XRDS in turn contains a ProviderID element with an XRI identifing the SAML authentication service provider (example: xri://@2idi or xri://@!23a7.c58d.4307.dd3a). An application consuming an SAML authentication service endpoint would then know to resolve the ProviderID XRI to obtain another XRDS with a service endpoint for the SAML authentication service provider's SAML metadata (this service is identified with the XRI Applications consuming SAML authentications know to cache the SAML metadata document once they retreive it because it won't change very often (and contains its own cache control metadata), so resolution of the second XRI to obtain the URI for the SAML metadata document only has to be done once for each new SAML authentication service provider. I'd say the same pattern applies here: applications consuming Higgins CIDs would only need to retreive the second XRI describing the context configuration metadata once for each new context configuration and then cache it, updating the cache as necessary after that. Hope this helps. (Note that I'm hopping on a plane this afternoon and will be sporadic on email until Monday.) Best, =Drummond From: Jim Sermersheim [mailto:jimse@xxxxxxxxxx] The state of discussion seemed to me to be here by the end of the call: We want a cid (when represented as an XRI) to be resolvable to an SEP in an XRDS document which represents a specific Higgins context. This context representation would contain context-specific metadata (such as the context's backing data store's endpoint, access configuration, etc.) as well as a way to discover the Higgins Context Provider's (CP) factoryClass[+factoryConfig] data. We want to allow but not require a separation of a specific context's representation from the factoryClass[+factoryConfig] needed to instantiate the IContext for that context. Allowing separation gives us the ability to configure a factory[+factoryConfig] once rather than at each context registration. To do this, we'd like to have an element which could contain either the factoryClass[+factoryConfig], or an xri which points to another service element (which could possibly be held by another XRI authority), where this other service element contains the factoryClass[+factoryConfig]. I'm going to reply to this after lunch with some XRDS examples, and a (probably poor) attempt at an example cid. Jim
|