How to let the SP query a specific dataSet or link to the RM from a PDS

[faragom]

This spec proposal derives from this discussion , although it is quite different. We decided to postpone implementing this to a later stage.

Background

• Currently, the SP can specify a source to be queried directly, by providing the name of a source on the spSource parameter (each SM ms is responsible to define how this attribute is passed on the SP request protocol)

• Direct data sources do not need any extended behaviour: they return a single data object, so the response is built from it (by returning all the attributes or the intersection between the received and the requested attributes)

• But PDS (and SSI, this spec could be extended for that case) hold multiple data sets and link objects, which requires the user to choose the object(s) to build the response from.

• Each dataset or link object has a well established and persistent identifier as the storeEntry identifier that, as recommended, must have a hierarchical and structured syntax.

• This user experience can be improved by allowing the SP to specify a list of dataSets and/or Links to retrieve from the PDS source

Considerations

• We can extend the syntax of the spSource parameter to allow specifying this list of objects to retrieve.

• The SP object selection can be treated in three ways:

  • force: Skip the selector and return the SP-selected objects
  • consent: Show the selector anyways, but with the SP-selected objects marked and not editable, so the user can just consent to the transfer of all or nothing.
  • suggest: Show the selector anyways, but with the SP-selected objects pre-marked, but allwoing the user to unmark and select others at will

• We can add a parameter to select the proper behaviour the SP wants on each occasion.

• As we define a syntax for this selector string, we need to fix a syntax for storeEntry object identifiers as well:

storeEntry.id syntax

• It must be:
  • structured: so it can be segmented if needed
    • : as a field separator
  • hierarchical: from the most general aspect (module identifier) to the most specific (subject identifiers)
  • unique: at least for a given seal module, for an issuer of data, and for a subject.
    • define a common prefix for all the SEAL project: urn:mace:project-seal.eu:id:
  • dataSets belong to a single subject, but links relate two subjects.
    • Both subjects must be represented
    • Identifier must be commutative (equally valid for any ordering of the subjects)
    • Order the identities by alphabetic order
  • all variables are urlencoded, so special characters are converted to %XX syntax

Proposed syntaxes:

urn:mace:project-seal.eu:id:link:{module_id}:{linkIssuer_id}:{firstIdentity}:{secondIdentity}

urn:mace:project-seal.eu:id:dataset:{module_id}:{identity_issuer}:{subject}

PDS search string syntax

Main syntax rules:

• An empty string means not even the source is fixed
• If not empty, fields mjust be provided incrementally from left to right.
• Fields marked as optional can be skipped (substituted by emtpy strings)

Syntax of the search string:

{source_id}|{mode}|{entry_id_prefix};{entry_id_prefix};{entry_id_prefix}

• source_id: The name of the source connected to SEAL we want to query. For this case, it will always be 'PDS'.
• mode: (optional)(default: force), the user interaction mode as described above: suggest, force, consent
• entry_id_prefix: any prefix (or full string) of a storeEntry.id to match with.
  • One or more can be requested, as a ; separated list

Search

• The storeEntry.id would be searched in prefix-mode, but allowing wildcards
  • The SP specifies a list of partial or full storeEntry identifiers as a search.
  • To match all options in an internal field, substituite its value for a * character.
  • All the storeEntries where the beginning of storeEntry.id (ignoring the wildcarded parts) matches the search, are selected.
  • In the future, regular expressions on each sub-field of the identifiers could be allowed

Example:

storeEntry1.id -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:ES:subjectIdentifier'
storeEntry2.id -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:GR:subjectIdentifier'
search -> 'urn:mace:project-seal.eu:id:dataset:eIDAS'
result: [storeEntry1, storeEntry2]

storeEntry1.id -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:ES:subjectIdentifier'
storeEntry2.id -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:GR:subjectIdentifier'
search -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:ES'
result: [storeEntry1]

storeEntry1.id -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:ES:subjectIdentifier'
storeEntry2.id -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:GR:subjectIdentifier'
search -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:ES:subjectIdentifier'
result: [storeEntry1]

storeEntry1.id -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:ES:subjectIdentifier'
storeEntry2.id -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:GR:subjectIdentifier'
search -> 'urn:mace:project-seal.eu:id:dataset:eIDAS:*:subjectIdentifier'
result: [storeEntry1, storeEntry2]

Examples

Given all the above, here are examples of the incremental syntax we propose:

Requesting PDS source only (selector of objects will be shown):

spSource = "PDS"

Requesting PDS source and an eIDAS dataset (any eIDAS dataset from any country, with default behaviour):

spSource = "PDS||urn:mace:project-seal.eu:id:eIDAS"

Requesting PDS source and an spanish eIDAS dataset and asking for consent:

spSource = "PDS|consent|urn:mace:project-seal.eu:id:dataset:eIDAS:ES"

Requesting PDS source and an spanish eIDAS dataset, with its link to an uji.es identity (from any link module and issuer):

spSource = "PDS|consent|urn:mace:project-seal.eu:id:dataset:eIDAS:https%3A%2F%2Feidas.redsara.es;urn:mace:project-seal.eu:id:link:*:*:*:https%3A%2F%2Feidas.redsara.es:*:uji.es"

[faragom]

A practical case that wa son the mails. I document it here

For an module like EduGAIN, whe multiple attributes can be available or not, depending on the IdP, we need a persistent and robust way to determin the identifier, by establishing a strict order for the attributes to be checked if existing and used:

• Attribute order for the identity_issuer:

  schacHomeOrganization
  o
  eduPersonOrgDN 
  "default-issuer"

• Attribute order for the subject :

  schacPersonalUniqueID
  schacPersonalUniqueCode
  eduPersonTargetedID
  eduPersonPrincipalName
  "default-subject" 

[faragom]

As discussed on the mail thread:

1. we drop eduPersonTargetedID from the list.
2. We add the future persistent identifier urn:oasis:names:tc:SAML:attribute:subject-id to the list (as it is expected to be widely supported in the future)

• Updated attribute order for the subject :

  schacPersonalUniqueID
  schacPersonalUniqueCode
  urn:oasis:names:tc:SAML:attribute:subject-id
  eduPersonPrincipalName
  "default-subject"