Difference between revisions of "Context Discovery"

Revision as of 02:21, 7 March 2007

Design Goals

In addition to all the previous design goals, here is one more that is 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 used in what is termed here the Context Registry. For example, if there is an OpenID service out there Higgins should be able to learn about it and connect to it without modification. [Note: there is Higgins-specific stuff in the Context Provider Registry (see below).

ContextIds

Beyond what is written here ContextId this proposal includes the following additional conventions:

1. A XRI-type ContextId MUST be resolvable to a single Service EndPoint (SEP) block in the XRDS document to which it's authority segment resolves.
2. XRI-type ContextIds in Higgins are considered to be comprised of: an authority segment (e.g. =drummond), optionally followed a path segment (e.g. "/bizcard") optionally followed by a type segment (e.g. "/+OPENID"). If the XRI string ends in one of the following sub-strings, then this sub-string is considered the type segment. [Anything remaining to the right of the authority segment and to the left of this sub-string is considered the path]:
   1. +OPENID
   2. +LDAP
   3. +SQL
3. iname to ContextId Mapping: inames (e.g. =drummond) by themselves are not fully qualified (see above). Either a path or a type (or both) MUST be appended to the root iname.
4. We find the SEP block in the XRDS by matching on BOTH the path (if any) to the <Path> element and the type (if any) to the <Type> element

More about fully qualified XRIs

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 one 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. He's using a Higgins Identity Agent.

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 many SEPs (SEPs: Service Endpoints: <Service> blocks in the XRDS document that =drummond resolves to) and then it looks at the type of each SEP and looks in the Context Provider Registry to see what service types are supported by this installation of Higgins, and dynamically generates N i-cards--one for each service type that Higgins understands. For example, one of the service types that this installation of Higgins understands is OpenID, and since Drummond has provisioned an OpenID service, Higgins will create a URI-i-card is whose ContextId is '=drummond/+OPENID'.

[The preceding paragraph is just setting the stage. The next part is important]

Paul can now click on his new URI-i-card and inspect its attributes. Here's what happens:

1. The URI i-card passes the ContextId to "IdAS" and asks it to return an IContext
2. What we'll call "IdAS" (probably IdAS.utils) splits the ContextId into three segments: authority, path, and type as described above. So '=drummond/+OPENID' is spit into authority='=drummond', path=null, type='+OPENID' . Note: '+OPENID' is really just an alias for the xri-for-openid, namely, "http://openid.net/server/2.0".
3. IdAS then calls XRI.resolveByPathAndType("=drummond", null, "http://openid.net/server/2.0"). The first arg is the iname, the third 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).
4. 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.
5. That factory initiates itself with the factory config elements (column 3 in Provider Registry table)
6. 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". This supposedly has Drummonds business card attributes. Sequence:

1. The i-card manager invokes IURICard.getContext() on this i-card
2. The i-card object uses "IdAS" to get an IContext
3. The i-card invokes an XRI resolver: XRI.resolveByPathAndType("=drummond", "bizcard", null)
4. This resolves to the file "xrds2" and within it the SEP whose <Path> element matches "bizcard". (Note: in this example the ContextId uses only path matching to find the SEP)
5. This SEP block contains the context-specific configuration elements that describe the context
6. We look up in the Context Provider Registry by type "+LDAP" for a Context Provider

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.

.

Context Registry

Purpose: To map a ContextId to a Service endpoint description.

The registry leverages XRI resolution to a set of XRDS files. <Service> blocks in the file provide 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 endpoint description looks like in file 'xrds2':

<Service>
   <Type>xri-for-ldap-type</Type>  
   <Path select="true">bizcard</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.

Context Provider Registry

Purpose:: To map a service Type to an IContextFactory, along with any factoryConfig metadata needed (if any). Implemented using XRI resolution.

Here's how it would work if the Type was xri-for-ldap: This Context Provider Registry would construct the xri: @WISER*higgins_imp*(xri-for-ldap). It constructs this xri because it has been configured to know and trust @WISER as the registry of Higgins Context Providers. It "knows" that this organization has their registry at *higgins_imp and that they take a crossref to the Type as the final segment (could also be: @WISER*higgins_imp/xri-for-ldap)

In the above @WISER is just a place holder for 'an entity that is trusted by the community to, and has taken on the burden to, run a registry.'

.

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