Context Discovery

Design Goals

• 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
• Simple things are simple. We want an approach where a OpenID XRI (or URI) can be referred to by a Higgins i-card using a ContextId of the same value as this XRI (or XRI) and presented as an IContext without any modification of the XRDS to which the OpenID XRI resolves. In other words, armed only with an OpenID XRI/URI, the Higgins Identity Agent should be able to present its attributes to the user (read-only) in the i-card manager. OpenID servers don’t need any contextConfig or factoryConfig to use them.
• Complex things are possible. Beyond the simple OpenID case, we also want to support LDAP, SQL, etc. backed Context which do need contextConfig and probably factoryConfig metadata in order to be presented as an IContext.

Use Cases

	Use Case	ContextId	Resolves to	Finding the <Service> block by
1	Higgins OpenID URI i-card	=drummond	xrds1	matching <Type> value of "http://openid.net/server/2.0"
2	Higgins URI i-card	=drummond/vcard/+ldap	xrds2	matching <Path> value of "+ldap"
3	Higgins URI i-card	=drummond/webSurfingPersona/+sql	xrds3	matching <Path> value of "+sql"
4	Higgins URI i-card	@parityinc.net/AccountingDept/+ldap	xrds4	matching <Path> value of "+sql"
5	Higgins CardSpace-interoperable managed i-card	localhost/icardstore/236-86/+ldap	xrds5	matching <Path> value of "+sql"

.

Use case #1 details

User has an existing OpenID OP of "=drummond". They wish to manage this OP using the Higgins Identity Agent (specifcally the Higgins i-card manager). They create an OpenID URI-type i-card using the i-card manager. (This is a new special kind of URI i-card). During the process of creating the new i-card the user types in its URI value as "=dummond". This is the ContextId of the OpenID URI i-card. The user wishes to see the values of their attributes (i.e. the attributes defined by OpenID authentication) in the i-card manager. Sequence:

1. The OpenID URI-type i-card invokes an XRI resolver in an IdAS.utils package: XRI.resolveByType("=drummond", "http://openid.net/server/2.0"). The first arg is the ContextId, second is new; it 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)
2. IdAS.open searches IdASRegistry for an IContextFactoryClassName for the http://openid.net/server/2.0 service type, it finds org.eclipse.higgins.cp.openid.
3. That factory initiates itself with the factory config elements (column 3 in IdASRegistry table)
4. We do a <factory>.getInstance reading the “Other <Service> elements” from column 4 in XRDS Files table for the contextConfig data

Use case #2 details

User wants to view the IContext associated with a Higgins URI i-card whose ContextId is "=drummond/vcard/+ldap". Sequence:

1. The i-card manager invokes IURICard.getContext() on this i-card
2. The i-card invokes an XRI resolver: XRI.resolveByPath("=drummond/vcard/+ldap")
3. This resolves to the file "xrds2" and within it the service block whose <Path> element matches "+ldap"
4. We read <Type> value of the same service block and use it in IdASRegistry to look up an IContextFactory class name
5. Use this factory to getInstance an IContext

XRDS Files

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:

XRDS File	<Type> element's value	<Path> element's value	<Schema> element's value	Other elements
xrds1	http://openid.net/server/2.0	(not present)	(not present)	<URI>: url-of-OP</URI>
xrds2	xri-for-ldap	"+ldap"	url-of-schema-for-this-vcard	<SSL>True/False</SSL>,<port/>, and other LDAP-specific elements that identify the context dataset
xrds3	xri-for-sql	"+sql"	(not present)
xrds4	xri-for-ldap	"+ldap"	url-of-schema-for-this-departments-employee-directory	<SSL>True/False</SSL>,<port/>, and other LDAP-specific elements that identify the context dataset
xrds5	xrd-for-ldap	"+ldap"		<SSL>True/False</SSL>,<port/>, and other LDAP-specific elements that identify the context dataset

.

Here is what the service block looks like in xrds2:

<Service>
   <Type>xri-for-ldap-type</Type>  <-- don't know if this is required or not, since we're matching on <Path> not <Type>
   <Path select="true">+ldap</Path>
   <URI append="none">ldap server URL</URI> ...and 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)

Service Type	IContextFactory Class Name	other IContextFactory config data
http://openid.net/server/2.0	org.eclipse.higgins.cp.openid	??
xri-for-ldap	org.eclipse.higgins.cp.jndi	??
xri-for-sql	org.eclipse.higgins.cp.slq	??

.

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)"