| [higgins-dev] Another topic (or two) for Nov 2 phone call |
|
These have to do with claim/attribute mappings.
I had initially thought for simple cases, if we were to implement an IdAS "mapping provider" (a provider which could be plugged in front of a "real" provider), that the IdAS consumer could pass claim names into IdAS and IdAS (via the mapping provider) could map and emit attributes back out with claim names (rather than the Attribute type URIs used by the underlying provider).
It seems this actually can't be done however, since claim URIs may not be Higgins Attribute type URIs, and IdAS types must be Higgins Attribute URIs. If this isn't the case, I need clarification. If it is the case, I suppose we could skip this topic and move right into the next one:
claim/attribute mapping is now shown to happen inside I-Card Providers. It would be good if someone could step us through a flow of events where claim/attribute mappings occur. I assume the RST to the TS contains the claim names. At some point, the TP will talk to IdAS to read a DigitalSubject. Prior to doing this, the claim names must be mapped to attribute names (i.e. when asking for attribues of the DigitalSubject). Then, the attribute names will be mapped back to claim names to produce the token. If this is true, then the TS or TP must be talking back to the I-CardProvider which talks to IdAS on behalf of the TS/TP.
If this is true, what protocol / API is used between the TS/TP such that the TS/TP can get a <DigitalSubject/DigitalIdentity> thing? I don't use the word DigitalSubject, because the "thing" needs to be a set of claims, not attributes, and I don't use DigitalIdentity because that's what the STS produces, right? (or does "DigitalIdentity" not imply that it has been built/signed by an STS?)
Anyway, seeking clarification in this area.
Jim
|