Hello, On Jan 7, 2012, at 0.50, Colin Wallis wrote:
The general feeling is that 'responsibility' as you mention below, will be published/consumed via meta data.
But we need to determine what that actual attribute will be - whether we create one or re-use one (say from a SAML 2.0 profile).
On Jan 7, 2012, at 1.42, Gerald Beuchelt wrote:
As far as I can see there are two principal approaches:
1. An authoritative attribute provider is determined by policy, i.e. an authority within the group of operators defines who is authoritative. This will - most likely - have to be decided and configured upfront.
2. The relying party makes their own determination, based on its needs and policies. In this scenario, the RP has more flexibility to determine authoritativeness at runtime.
Thanks Colin and Gerald, the best solution I have found so far introduces a Linking Service, which allows the relying party to aggregate all user's attributes [1]. Allow me to bring in an example to better detail my original problem: An attribute named 'title' (possible values are Engineer, Doctor...) can be provided by many APs. Some of them can be IdPs (like a university where each member has a digital identity), others can be simple APs that rely on a federated IdP for authentication. If we consider that a user identity is composed by many other attributes ('name', 'residence'...), the scenario becomes quickly complex. All user's attributes are spread across different IdPs and APs. The only subject knowing where they are is the user himself. For simplicity's sake, let us suppose that all those IdPs and APs have already agreed to enter a federation or something like that. Chadwick and Inman proposed the introduction of a new entity: the Linking Service. I have found the proposal interesting, but I have not stopped looking and asking for possible alternatives.
So, in general, the problem is really a managerial problem, and not a technical one. However, meta data may help in making decisions at runtime.
I think the problem is technical too, as it requires to implement specific patterns for attribute discovery/aggregation, don't you agree? On Jan 7, 2012, at 2.36, Nat Sakimura wrote:
In OpenID Connect, the authorization server maintains the list of available attributes and their location. After user authorization, the relying party would be able to obtain the location (endpoint) and the access token to be used on the endpoint. The assurance level of the attribute source is another issue. It needs to be dealt with some kind of trust framework.
On Jan 7, 2012, at 10.47, Domenico Catalano wrote:
Last December, Smart team at Newcastle Univ showed a basic UMA-Openid connect integration (demo) for this purpose.
Thanks Nat and Domenico, I will look into OpenID specifications, but my work will be related to SAML only. On Jan 8, 2012, at 20.30, Patrick Curry wrote:
In highly regulated worlds, entity and attribute authorities are defined in support of either a corporate data model (e.g. Intel, which is controlled by the CEO), or a government data model (e.g. the US Dept of Defence Data Model implemented in the Defence Metadata Service and referenced in the DoD Architecture Framework (DODAF)) or a collaborative data model implemented in collaborative programmes or whole industry sectors (e.g. the aerospace and defence model for US Export Controls/ ITAR (International Traffic and Arms Regulations), similarly the data model supporting the Joint Strike Fighter programme). The situation is made complicated by the rules governing which party or person can update which values or attributes in which circumstances, which requires a taxonomy or at least a set of rules based on Common Policy. This is very similar to the federation scenarios which are very familiar to those involved in widely deployed PKI Federation.
Thanks Patrick, are any of the standards/data-models you mentioned publicly available? [1] Chadwick, Inman "Attribute Aggregation in Federated Identity Management" doi: 10.1109/MC.2009.143 http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5070036&isnumber=5070024 -- Mauro Levra Polytechnic University of Turin