Difference between revisions of "Context Discovery"

Revision as of 17:33, 1 March 2007

WARNING: After much discussion today (3/1) with Andy Dale, this revision is now obsolete. A new rev will be forthcoming

Design Goals

In addition to all the previous design goals, here are some more that were behind this proposal

• Higgins-ism free. Higgins is not in the service/protocol definition business. So the intuition here is that there shouldn’t be any higgins-isms in the XRDS documents. And there should be nothing special about how ContextIds are resolved to XRDS Service blocks (service endpoints). For example, if there is an OpenID service out there Higgins should be able to learn about it and connect to it without modification.

XRIs/URIs resolving to XRDS documents need to be qualified to be used as ContextIds

A key issue that is finally resolved in this proposal is that in Higgins a ContextId uniquely identifies a Context whereas an XRI (or URI) that resolves to a single XRDS document can, when looked at as "a provider of attribute sets" provide more than one set of attributes (effectively more than on Context) and thus does not uniquely identify a Context in the Higgins sense of the word.

For example the XRI '=drummond' may delegate to an OpenID service and simultaneously to a contact service. The set of attributes (and their values!) provided by each of these two services may be different (and usually are). Thus simply having an XRI does not by itself provide enough information to uniquely specify which possible attribute set (which Context) we're talking about. [It is also true that this same XRI may have other services unassociated with providing attributes at all (e.g. messaging services), thus underscoring the need to further qualify the XRI from a Higgins perspective]

Use Cases

The user is =paul.trevithick. He's using a Higgins service.

Use case #1

Paul has a friend who tells him his iname is '=drummond'. Paul is using Higgins 3.0 (the year is 2009). This version has an i-card manager that allows him to type in this iname whereupon it inspects the zillions of SEPs (SEPs: Service Endpoints: <Service> blocks in the XRDS document that =drummond resolves to) it looks at the type of each and looks in the Context Provider Registry to see what service types are supportable by Higgins and dynamically generates N i-cards for each service type that Higgins understands. For example, one of the service types that Higgins understands is OpenID, so a URI-i-card is created whose ContextId is '=drummond/+OPENID'. Paul can now click on his new URI-i-card and inspect its attributes.

When Paul click to view his new i-card the following steps happen:

1. The URI i-card splits off the +OPENID (for reasons of backward compatibility with existing XRDS documents that do not use the +OPENID tag alias) and invokes an XRI resolver in an IdAS.utils package: XRI.resolveByType("=drummond", "http://openid.net/server/2.0"). The

he first arg is the iname, the second is the target service <type>. We're telling the resolver to find the <Service> block that matches by matching on <Type> with the value provided. (See XRDS Files section below to see a description of the contents of xrds1).

1. IdAS searches Context Provider Registry to find a IContextFactory class name for the http://openid.net/server/2.0 service type, it finds org.eclipse.higgins.cp.openid.
2. That factory initiates itself with the factory config elements (column 3 in Provider Registry table)
3. We do a <factory>.getInstance reading the “Other <Service> elements” from column 4 in XRDS Files table for the contextConfig data

Use case #2

Paul wants to view an URI i-card whose ContextId is "=drummond/bizcard/+LDAP". This supposedly has Drummonds business card attributes. Sequence:

1. The i-card manager invokes IURICard.getContext() on this i-card
2. The i-card invokes an XRI resolver: XRI.resolveByType("=drummond", "bizcard/+LDAP")
3. This resolves to the file "xrds2" and within it the SEP whose <Type> element matches "bizcard/+ldap"
4. This SEP block contains the context-specific configuration elements that describe the context
5. We look up in the Context Provider Registry (by type "+LDAP) [Hey Andy, there's a little switcheroo there...how did we get from "bizcard/+LDAP" to just "+LDAP"?]

Use case #5 details

This is an example of a ContextId that will be stored in the metadata of the endpoint reference of the token service in the RST. It will be received by the Token Service, passed to a Token Provider and used by that provider to open up an IContext using IdAS. Mike has verified that MSFT CardSpace preserves this EPR metadata so this same approach will work using Higgins or CardSpace Identity Agents.

.

XRDS Files (examples)

Note: the combination of XRI resolution (if needed on a ContextId) plus the set of XRDS files constitutes a kind of "registry", but we're no longer referring to it that way here.

Each file provides the metadata for the ContextId to which it resolves so that a Higgins Context Provider might be found and that could be told enough about the endpoint to present it as an IContext instance.

The following table shows the elements within the matched <Service> block:

.

Here is what the service block looks like in xrds2:

<Service>
   <Type>xri-for-ldap-type</Type>  
   <Path select="true">+ldap</Path>
   <URI append="none">ldap-server-URL</URI> 
   ...other ContextConfig elements...
</Service>

See http://iss.xdi.org/moin.cgi/IserviceEndpointDefinitions for more examples of I-Service Endpoint definitions.

IdASRegistry

Maps an XRDS service type to an IContextFactory along with any factoryConfig metadata needed (if any)

.

Note: "xri-for-ldap" and "xri-for-sql" as used above will be defined by the OASIS XRI TC (they will probably look like say "+i-service*(+ldap)*($v*1.0)" and "+i-service*(+sql)*($v*1.0)"