| RE: [higgins-dev] Another topic (or two) for Nov 2 phone call |
|
Inline below From:
higgins-dev-bounces@xxxxxxxxxxx [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Jim Sermersheim These have to do with claim/attribute mappings. An area I’ve been thinking a lot about in the last week or so…
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 I think perhaps it can be done: A Context could use a schema, that for
example, treated the Microsoft CardSpace surname
claim type as a higgins:attribute: <owl:ObjectProperty rdf:about="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"> <rdfs:domain rdf:resource="#Person"/> <rdfs:range rdf:resource="&higgins;#StringSimpleAttribute"/> <rdfs:subPropertyOf rdf:resource="&higgins;#attribute"/> </owl:ObjectProperty> Where #Person is a
subclass of higgins:DigitalSubject. This is why I deleted last week the component called “Attribute/Claim
Mapping” from here.
The I-Card Provider must produce Claims, but we don’t need a separate The distinction between a claim and an attribute is more a matter
of usage than the nature of the thing itself. Claims are a kind of attributes
that are intended for external consumption by relying parties and thus are
under some special constraints (e.g. they should be used (a) as sparingly as
possible and (b) must be in the namespace that the relying party understands
(c) are often packaged together and digitally signed (d) might even be cryptographically
blinded still further (e.g. with idemix), etc.) but they’re attributes
all the same. I now think that an IdAS Context can offer to a I-Card Provider or
a Token Provider a higgins:attribute
that, as shown above, uses a Claim namespace (dictated by the RP) and
that can be trivially converted into a Claim for external consumption. 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 Well, I was trying to indicate that it is the responsibility of the
I-Card Provider. As I mention above, it can delegate this responsibility to a
Context Provider. <snip>. |