Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Context Discovery

Revision as of 23:45, 26 April 2007 by Paul.socialphysics.org (Talk | contribs) (Use case #5 details)

Version 4This draft reflects Paul and Drummond's 4.26.2007 conversation.

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 ContextId MUST be resolvable to a single Service Endpoint (SEP) in the XRDS document to which it's authority segment resolves. Note: in the case where the identifier of the XRDS document is a http(s): URL or file:// URI then it is cast into an XRI before being processed as described below (e.g. http://example.com/something would cast to $(http://example.com/something))
  2. ContextIds in Higgins are considered to be comprised of:
    1. a first segment (called the authority segment)
    2. a second segment (the first segment of the XRI path) (e.g. "+bizcard")
    3. no third segment
  3. For XRI-type ContextIds the authority segment is preceded by '=' or '@'.
  4. Any iname (i.e. just the authority segment of an XRI) is a legitimate ContextIds (consisting only of the first segment (the path segment is null. The null path value is used to select the SEP)
  5. We find the SEP block in the XRDS by matching on the path (even if null) to the <Path> element of an SEP

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) calls XRI.resolve(ContextId) to return the SEP. We're telling the resolver to find the <Service> block that matches by matching on <Path> with the value provided. (See XRDS Files section below to see a description of the contents of xrds1).
  3. IdAS looks up the value of the <Type> element in the SEP (this will be used below)
  4. IdAS searches the Context Provider Registry to find a IContextFactory class name for the Type just found. It finds, for example org.eclipse.higgins.idas.cp.openid.
  5. That factory initializes 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 Drummond's 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.resolve("=drummond/+bizcard")
  4. This resolves to the file "xrds2" and within it the SEP whose <Path> element matches "+bizcard".
  5. This SEP block contains the context-specific configuration elements that describe the Context. It also contains the value "+ldap" in the Type element
  6. We look up in the Context Provider Registry by type "+ldap" for a suitable 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.

Use Case Kind of i-card ContextId Context Description Resolves to ...within which we find the <Service> block by
1 Higgins URI i-card =drummond/+openid Drummond's i-name provider has provisioned OpenID services for this i-name. This i-name partially identifies a Context holding the attributes provided by OpenID auth xrds1 matching <Path> element's value of "+openid"
2 Higgins URI i-card =drummond/+bizcard Drummond has a (single-DS) Context that holds business card attributes. xrds2 matching <Path> element's value of "+bizcard"
3 Higgins URI i-card =drummond/+webSurfer Drummond uses HBX in his browser and in the Higgins i-card manager he has defined a single-DS Context with the set of attributes he's happy to share with run of the mill websites. It contains only non-identifying information. xrds3 matching <Path> element's value of "+webSurfer"
4 Higgins URI i-card @cordance/+Accounting Cordance (Drummond's employer) maintains a directory of all employees. A multi-DS Context. xrds4 matching <Path> element's value of "+Accounting"
5 Higgins CardSpace managed i-card localhost/attstore/2386 This is the Context behind some card that the Higgins Token Service issued. xrds5 matching <Path> element's value of "attstore/2386"

.

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:

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 (not present) bizcard url-of-schema-for-this-vcard <SSL>True/False</SSL>,<port/>, and other LDAP-specific elements that identify the context dataset
xrds3 (not present) webSurfer (not present)
xrds4 xri-for-ldap Accounting url-of-schema-for-this-departments-employee-directory <SSL>True/False</SSL>,<port/>, and other LDAP-specific elements that identify the context dataset
xrds5 (not present) attstore/2386 <SSL>True/False</SSL>,<port/>, and other LDAP-specific elements that identify the context dataset

.

Here is what the service endpoint description looks like in file 'xrds2'. Remember, in this use case the ContextId has a null Type, so no matching on <Type> is used. Nevertheless, the <Type> element MUST be present because it is used to look up the Context Provider in the Context Provider Registry (see next section):

<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.'

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

.

Locally Deployed Context Provider Registry

Purpose:: To maintain a list of the locally installed/available Context Providers

Perhaps the IContextFactory config data from this registry would be added to (override) the IContextFactory config data made available by the Context Provider Registry mentioned above.

IContextFactory Class Name other IContextFactory config data
org.eclipse.higgins.idas.cp.openid ??
org.eclipse.higgins.idas.cp.jndi ??
org.eclipse.higgins.idas.cp.sql ??

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

Back to the top