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

Relationship Brokering With R-Cards

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}

Higgins logo 76Wx100H.jpg

Version

This page is a place to design the implementation of an important and complex r-card use case. This design work is part of Higgins 1.1.

Use Case Summary

Preconditions:

  • A user named Alice wishes to use an application called App
  • App requires and consumes a specific set of claims/attributes about Alice from Alice.
  • App is capable of permissioned data sharing using R-Card technology.
  • App chooses to leave the choice of whether Alice provides a "one shot" set of claims/attributes or a durable permissioned data sharing connection to this set of claims/attributes. It expresses this by advertising an RP policy that requires a set of "normal" claim URIS and leaves optional the special resource-udr claim.

Flow:

  • Alice goes to RP site. Alice's selector reads Apps RP policy (as described above).
  • The selector pops up and Alice selects one (or more) of her choice of regular I-Cards or R-Cards [if needed and if N>1 card selection isn't supported, then the selector pops up N>1 times]
  • N security tokens (one per card) are conveyed to App
  • Security tokens from R-Cards contain the resource-udr meta claim whose value is a reference to the Entity and its Attributes. App can "pull" the values of these Attributes at any time (well, as long as Alice wants them to be able to get them!).

Actors

R-card-brokering.png

Sequence1

R-card-brokering-sequence-v3.png

  1. App sends a getDigitalIdentity++() (see below) request to Alice's selector.
  2. The selector pops up displaying the text "App would like access to data on some of your cards. Click on one or more cards to grant this permission."
  3. Alice clicks on the Fabrikam card
  4. Normal m-card RST
  5. Normal m-card RSTR
  6. Normal post of Fabrikam token to App
  7. App validates token and extracts the resourceUDI claim value. It resolves the resourceUDI to the R-Card Issuer's IDS SEP (e.g. XDI service layer over IdAS) and thereby reads the IDS's IMI-RPSP (relying party's security policy). This indicates the type of access token that IDS requires in order to auth and gain access to the r-card's Context & Entity data objects, as well as the set of required claims, as well as the EPR of where such a token can be found. In this case the EPR == Fabrikam's "R-Card Issuer STS"
  8. App does an RST to Fabrikam's STS
  9. Fabrikam's STS generates and returns the access token
  10. App validates the access token and uses it to open the Context (doing the moral equivalent of an IdAS Context.open(<auth materials>))

Sequence 2

This is a variant of sequence 1 above. It uses John Bradley's "private discovery" proposal to discover the XRD in a claim value of token #1.

R-card-brokering-seq2.png


  1. as in sequence 1
  2. as in sequence 1
  3. as in sequence 1
  4. as in sequence 1
  5. as in sequence 1
  6. as in sequence 1
  7. App validates token and extracts the resourceUDI claim value. It also extracts the value of a new claim "resource-udi-xrd" which is the XRD that describes the SEP of the resourceUDI from which it learn's the IDS's IMI-RPSP (relying party's security policy). This policy indicates the type of access token that IDS requires in order to auth and gain access to the r-card's Context & Entity data objects, as well as the set of required claims, as well as the EPR of where such a token can be found. In this case the EPR == Fabrikam's "R-Card Issuer STS"
  8. as in sequence 1
  9. as in sequence 1
  10. as in sequence 1

Sequence 3

This is another variant of sequence 1 above. It uses John Bradley's "private discovery" proposal to discover the XRD in a claim value of token #1. The XRD includes the necessary access token.

R-card-brokering-seq3.png

  1. as in sequence 1
  2. as in sequence 1
  3. as in sequence 1
  4. as in sequence 1
  5. as in sequence 1
  6. as in sequence 1
  7. App validates token and extracts the resourceUDI claim value. It also extracts the value of a new claim "resource-udi-xrd" which is the XRD that describes the SEP of the resourceUDI from which it learn's the IDS's IMI-RPSP (relying party's security policy). This policy indicates the type of access token that IDS requires in order to auth and gain access to the r-card's Context & Entity data objects, as well as the set of required claims, as well as the EPR of where such a token can be found. In this case the EPR == Fabrikam's "R-Card Issuer STS". It directly extracts token #2 from the XRD.
  8. skip
  9. skip
  10. as in sequence 1

getDigitalIdentity++()

Like a regular getDigitalIdentity plus:

  • indicator of the desire for N>1 tokens
  • link to "RP context providing" text
  • ...plus the regular stuff

See Also

Back to the top