Ken, Whether an attribute is a plain attribute (birthdate, age = 29) or a derived attribute (age is in valid range) is not really a question of assertion but of the attribute policy complexity. An example of an asserted attribute would be a treatment relationship assertion (TRC), which is asserted by the patient's smartcard. Yet it is questionable if a TRC claimed by the doctor (because the patient cannot use/does not have a smartcard) is not assured. Even it is kind of a self-assured attribute, the context (audit, professional code of conduct, threat of punishment) will lead to quite reliable data in practice. Is there somewhere a definition of an asserted, validated and assured attribute? - Rainer Am 27.02.2012 um 13:03 schrieb Dagg, Kenneth:
Context Topic
To me Context is a valid concept but I believe that it is only an issue for Identity Assertion Providers and is not an issue for Identity Attribute Providers or for Identity Attribute Assertion Providers. In my mind, an Attribute Provider supplies content (e.g., age is 29) while an Attribute Assertion Provider supplies assertions about content (e.g., age is valid).
My rationale is: an Identity Attribute (Assertion) Provider, as an Authoritative Party, maintains Identity Attributes to a Level of Assurance that they provide (content or assertion) upon a request from a service provider. In other words, they are either an authoritative party of an attribute or not. I'm not sure if the context in which the IAP has gathered the attribute matters to them.
Where context matters, I believe, is when Identity Assertions (as opposed to Identity Attribute Assertions) are made. In this case, the context in which they have validated an identity matters greatly in terms of the assertion it can make concerning the identity of a subject.
To me, the attribute assertion world is easier than the identity assertion world as, I believe, Identity Attribute Providers (whether they provide actual content or just assertions about content) is just an extension of credential service providers. The extension is not simple as there are several policy/legal issues (e.g., consent) that have to be addressed.
Where I believe context also matters is in the Service Provider space. However, the context in which a service provider uses Identity Attributes is set by the attributes they are allowed (legally/by policy) to gather in order to 1) uniquely identify the individual, 2) determine eligibility for the service, and 3) deliver service.
Query Language Topic
I agree with the statement, "With no standard/normative query language, there is no way to ask a broad set of identity providers anything about the entities they are authoritative for. When a service provider needs to ask dozens of identity providers across the globe "Is this person of legal age to use my service?"
To me, to satisfy this, requires the service provider to either make a "discovery" like query or, the provider, as a federation member, having metadata to describe the attributes it maintains. The query to obtain the attributes then becomes a standard protocol.
I would further suggest, given this rational, that the Query Language be merged into the Protocol section as it seems to belong there instead of being a section on its own.