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.
Difference between revisions of "Context Discovery"
m (Added tag for left menu) |
|||
| (120 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == | + | {{#eclipseproject:technology.higgins}} |
| − | + | == Intro == | |
| − | + | This page explains the process for [[Context]] discovery in the [[Identity Attribute Service]]. Note that this page only provides a general descripion and examples of the process. For specific implementation details, see: | |
| − | + | ||
| − | + | * [[Context Discovery Components]] for a description of the components that have been implemented for context discovery. | |
| − | + | * [[ContextId]] --the formal ABNF definition | |
| − | + | ||
| − | + | == General Process == | |
| − | + | Context discovery in Higgins consists of the following four general steps: | |
| − | + | ||
| − | + | # The process starts with passing the [[ContextId]] for which context discovery is needed to IdASRegistry. | |
| − | + | # IdASRegistry uses the [[ContextId]] to obtains a context descriptor (typically an XRDS file) that contains at least one context type, zero or more URIs, and an optional configuration map. | |
| − | + | # From the context type, IdASRegistry finds a context factory that can instantiate a context for the given [[ContextId]]. | |
| − | + | # IdASRegistry returns a context factory that has been configured. | |
| − | + | ||
| − | + | == Examples == | |
| − | + | ||
| − | + | === Example #1: Typing in an I-Name === | |
| − | + | Paul is using a version of Higgins Identity Agent that allows him to type the i-name of a friend, '''=drummond''' into his i-card manager. His i-card manager then calls IdASRegistry which performs the following steps: | |
| − | + | # Resolves the i-name into an XRDS document to discover the service endpoints (SEPs - the <Service> blocks in the XRDS document). From a Higgins standpoint, each SEP corresponds to a Higgins context descriptor. | |
| − | + | # Looks at the <Type> element of each SEP to discover its context type. | |
| − | + | # Looks in the Context Provider Registry for that Higgins installation to see what service types are supported by this installation. | |
| − | + | # 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 r-card is whose ContextId in ContextXRI format is '''=drummond/$context+openid'''. | |
| − | + | ||
| − | + | === Example #2: Clicking on an R-Card === | |
| − | + | Paul wants to view an r-card whose ContextId is '''=drummond/$context+bizcard'''. This supposedly has Drummond's business card attributes. The sequence is: | |
| − | + | # The i-card manager invokes IURICard.getContext() on this i-card. | |
| − | + | # The i-card object calls IdASRegistry.getContextFactory(contextId) to find an IContextFactory that can instantiate an IContext for the r-card's IContextId. | |
| − | + | # IdASRegistry obtains the context descriptor (in this case, an XRDS document retrieved via XRI resolution of '''=drummond/$context+bizcard'''). | |
| − | + | # The context descriptor contains one or more context types, which are used by IdASRegistry to look up a suitable context factory. | |
| − | + | # The IContextFactory is returned to the i-card object, which then calls the factory's createContext(contextId) method in order to get back an IContext object for the i-card's IContextId. | |
| − | + | ||
| − | + | === Example #3: Token Received by Token Service === | |
| − | + | A ContextId, '''localhost/attstore/2386''' is stored in the metadata of the endpoint reference of the token service in the RST. It is received by the Token Service, passed to a Token Provider and used by that provider to open up an IContext using IdASRegistry. (Mike has verified that MSFT CardSpace preserves this EPR metadata so this same approach will work using Higgins or CardSpace Identity Agents.) | |
| − | + | ||
| − | + | == Example XRDS Files == | |
| − | + | See [[ContextDiscoveryComponents]] for example XRDS files. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | . | + | |
Latest revision as of 08:39, 15 March 2008
{{#eclipseproject:technology.higgins}}
Contents
Intro
This page explains the process for Context discovery in the Identity Attribute Service. Note that this page only provides a general descripion and examples of the process. For specific implementation details, see:
- Context Discovery Components for a description of the components that have been implemented for context discovery.
- ContextId --the formal ABNF definition
General Process
Context discovery in Higgins consists of the following four general steps:
- The process starts with passing the ContextId for which context discovery is needed to IdASRegistry.
- IdASRegistry uses the ContextId to obtains a context descriptor (typically an XRDS file) that contains at least one context type, zero or more URIs, and an optional configuration map.
- From the context type, IdASRegistry finds a context factory that can instantiate a context for the given ContextId.
- IdASRegistry returns a context factory that has been configured.
Examples
Example #1: Typing in an I-Name
Paul is using a version of Higgins Identity Agent that allows him to type the i-name of a friend, =drummond into his i-card manager. His i-card manager then calls IdASRegistry which performs the following steps:
- Resolves the i-name into an XRDS document to discover the service endpoints (SEPs - the <Service> blocks in the XRDS document). From a Higgins standpoint, each SEP corresponds to a Higgins context descriptor.
- Looks at the <Type> element of each SEP to discover its context type.
- Looks in the Context Provider Registry for that Higgins installation to see what service types are supported by this installation.
- 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 r-card is whose ContextId in ContextXRI format is =drummond/$context+openid.
Example #2: Clicking on an R-Card
Paul wants to view an r-card whose ContextId is =drummond/$context+bizcard. This supposedly has Drummond's business card attributes. The sequence is:
- The i-card manager invokes IURICard.getContext() on this i-card.
- The i-card object calls IdASRegistry.getContextFactory(contextId) to find an IContextFactory that can instantiate an IContext for the r-card's IContextId.
- IdASRegistry obtains the context descriptor (in this case, an XRDS document retrieved via XRI resolution of =drummond/$context+bizcard).
- The context descriptor contains one or more context types, which are used by IdASRegistry to look up a suitable context factory.
- The IContextFactory is returned to the i-card object, which then calls the factory's createContext(contextId) method in order to get back an IContext object for the i-card's IContextId.
Example #3: Token Received by Token Service
A ContextId, localhost/attstore/2386 is stored in the metadata of the endpoint reference of the token service in the RST. It is received by the Token Service, passed to a Token Provider and used by that provider to open up an IContext using IdASRegistry. (Mike has verified that MSFT CardSpace preserves this EPR metadata so this same approach will work using Higgins or CardSpace Identity Agents.)
Example XRDS Files
See ContextDiscoveryComponents for example XRDS files.