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