180 likes | 279 Views
The Attribute and the ecosystem. Topics. Basics Common Schema LOA of attributes Privacy Naming Complexity and Extensibility Tagging Complexity vs Metadata IdP releasing vs SP asking Query languages Dealing with Aggregation. Killer Attributes (and the applications that love them).
E N D
Topics • Basics • Common Schema • LOA of attributes • Privacy • Naming • Complexity and Extensibility • Tagging • Complexity vs Metadata • IdP releasing vs SP asking • Query languages • Dealing with Aggregation
Killer Attributes (and the applications that love them) • Human readable identifiers • Email address, eppn, display name, etc • Opaque identifiers • ePTID • Affiliation • Citizenship • Over legal age
Types of attributes • Institutional • Organizational • Reassertion of Official attributes • Temporal – geolocation, etc. • Community or collaboration asserted • Formal – Virtual organizations, groups • Informal – reputation systems, FoF • Self-asserted
Common Schema NIEM – National Information Exchange Model – www.niem.gov eduPerson -http://middleware.internet2.edu/eduperson/ http://www.terena.org/activities/tf-emc2/schac.html Accessability schema - http://www.w3.org/WAI/ and http://www.w3.org/WAI/intro/uaag.php http://doc.esd.org.uk/IPSV/2.00.html
Naming Oids vs URNs vs URLs vs URI’s vs Registering name spaces
Privacy • Which attributes are PII? • ePTID – opaque, non-correlating, but 1-1 • IP address • Which jurisdiction applies? • IdP? SP? Nationality of user? • Which require consent and for what purpose?
Authorization – Problem Statement • In a federated landscape, with scale in mind, groups more than identities control access • But attributes may express, in addition or instead, a user's relationship with the authenticating organization, membership in groups, or possession of roles or entitlements that signify permission to access application resources. In such cases, authorization may be delegated or distributed to the authenticating organization, or even across additional organizations. This is a relatively common pattern when the authorization policy is simple (typically all or nothing) and applies to large numbers of users at multiple organizations. It is less common as policies become more complex and fine-grained.
Groups • Local Groups • User Identification • Provisioning (and Deprovisioning) • Representation • isMemberOf • eduPersonEntitlement • Groups with Federated Members • Federated Groups • Privacy Implications • Visibility of members to other members • Sharing groups across services
Of Entitlements and Attributes • In entitlements, SP community passes business logic to IdP’s, who compute authorization and pass entitlement • To scale, must have common license terms • SP’s need to be willing to expose business logic • In attributes, IdP’s pass attributes to SP for authorization • Raises privacy issues • To scale, must have shared community attributes
Some key issues Which schema Knowing which IdP to ask for which attributes, especially as we get into aggregation How to ask, e.g. over 18 Making values extensible, so that they can be tagged, like validation, date, terms of use
Attribute Release SP Asking vs. IdP Releasing Specifying requirements (queries, metadata, policy files, web pages, etc.) Consent
Attribute aggregation • At the IdP • Already doing internal aggregation • Can arrange bulk feeds – e.g. IEEE member • At the SP • Already in the Shib code • At an intermediate point • Portals and gateways do this now • Can greatly simplify trust
“Over legal age” • Use cases are legion and confusing • Legal age of the web site country • Legal age of the IdP country • Legal age of the identity holder’s country • Authoritative sources and delegation • Query languages
Complexity and Extensibility • Complexity • Tagging within attribute vs use of metadata vs context • Extensibility • The ability to add new controlled values • How much flat attribute proliferation can be managed through a structured data space? • DRM of metadata
Principles of the Tao 属性之道 Least privilege/minimal release Using data “closest” to source of authority Late and dynamic bindings where possible Dynamic identity data increases in value the shorter the exposure. If identity data is cached away from the source there is increased likelihood of staleness and over-exposure which can lead to privacy and data accuracy concerns.
Beyond the first horizon • LOA of attributes • Specifying semantic rules • Shifting from attribute values as text strings to rich signed data • Terms of use • Time limits • etc