Attributes from multiple APs
Hello everyone, I am starting a thesis work on attributes management and aggregation in a federated identity environment and I am trying to figure out how to address attributes resolution in a scenario where there are multiple Attribute Providers. The main issue is: how does a relying party know which AP is responsible for a given attribute? As I am doing a research, I would like to know if in Kantara this problem has been faced and, if so, how you have solved it. Thank you for your time and consideration. Best Regards, Mauro -- Mauro L Polytechnic University of Turin
Hi Mauro It is a good question and one which along with many others, the Kantara Attribute Management Discussion Group has within its scope. 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). Cheers Colin
Date: Tue, 3 Jan 2012 19:43:50 +0100 From: s172556@studenti.polito.it To: community@kantarainitiative.org Subject: [Kantara - Community] Attributes from multiple APs
Hello everyone,
I am starting a thesis work on attributes management and aggregation in a federated identity environment and I am trying to figure out how to address attributes resolution in a scenario where there are multiple Attribute Providers. The main issue is: how does a relying party know which AP is responsible for a given attribute? As I am doing a research, I would like to know if in Kantara this problem has been faced and, if so, how you have solved it.
Thank you for your time and consideration.
Best Regards,
Mauro
-- Mauro L Polytechnic University of Turin _______________________________________________ Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
Mauro - 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. 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. Best, Gerald On Jan 6, 2012, at 18:50 , Colin Wallis wrote:
Hi Mauro
It is a good question and one which along with many others, the Kantara Attribute Management Discussion Group has within its scope.
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).
Cheers Colin
Date: Tue, 3 Jan 2012 19:43:50 +0100 From: s172556@studenti.polito.it To: community@kantarainitiative.org Subject: [Kantara - Community] Attributes from multiple APs
Hello everyone,
I am starting a thesis work on attributes management and aggregation in a federated identity environment and I am trying to figure out how to address attributes resolution in a scenario where there are multiple Attribute Providers. The main issue is: how does a relying party know which AP is responsible for a given attribute? As I am doing a research, I would like to know if in Kantara this problem has been faced and, if so, how you have solved it.
Thank you for your time and consideration.
Best Regards,
Mauro
-- Mauro L Polytechnic University of Turin _______________________________________________ Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
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. Nat On Saturday, January 7, 2012, Gerald Beuchelt <work@beuchelt.com> wrote:
Mauro - 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. 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. Best, Gerald
On Jan 6, 2012, at 18:50 , Colin Wallis wrote:
Hi Mauro
It is a good question and one which along with many others, the Kantara Attribute Management Discussion Group has within its scope.
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).
Cheers Colin
Date: Tue, 3 Jan 2012 19:43:50 +0100 From: s172556@studenti.polito.it To: community@kantarainitiative.org Subject: [Kantara - Community] Attributes from multiple APs
Hello everyone,
I am starting a thesis work on attributes management and aggregation in a federated identity environment and I am trying to figure out how to address attributes resolution in a scenario where there are multiple Attribute Providers. The main issue is: how does a relying party know which AP is responsible for a given attribute? As I am doing a research, I would like to know if in Kantara this problem has been faced and, if so, how you have solved it.
Thank you for your time and consideration.
Best Regards,
Mauro
-- Mauro L Polytechnic University of Turin _______________________________________________ Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
-- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
Mauro et al, in the consumer world, attribute control (if there is any at all) is as Nat and Gerald describe. Anything goes. Technology proliferation encourages a Tower of Babel. 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. As it happens, this week I will be sitting down in a Norwegian military base with 14 other nations, including IT, US, UK, FR - and NATO. (Italy heads a parallel work item on Legal). We are working on Cyber Situational Awareness (Cyber SA), which requires an agreed attribute schema to support the kinds of information that governments and critical national infrastructure etc providers need to share. In two weeks, I will be with the TMForum in Madrid, which is working on developing a set of Cyber SA metrics. I see Kantara potentially providing the certification regime for attribute providers and, further, data quality. I am also involved in EUSTIC with UK, German and Austrian colleagues, which is submitting a bid to the European Commission for funding for a wide range of trust framework enabling research and development. This includes attribute management. We will know if the bid is successful in March. If it isn't, then the EUSTIC Partner Alliance will press ahead with smaller set of trust-related activities. I hope this helps. If your work can relate to the above, that would be good. regards, Patrick Patrick Curry Director British Business Federation Authority - BBFA Ltd M: +44 786 024 9074 T: +44 1980 620606 patrick.curry@federatedbusiness.org www.federatedbusiness.org – a not-for-profit, self-regulating body On 7 Jan 2012, at 00:42, Gerald Beuchelt wrote: Mauro - 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. 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. Best, Gerald On Jan 6, 2012, at 18:50 , Colin Wallis wrote:
Hi Mauro
It is a good question and one which along with many others, the Kantara Attribute Management Discussion Group has within its scope.
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).
Cheers Colin
Date: Tue, 3 Jan 2012 19:43:50 +0100 From: s172556@studenti.polito.it To: community@kantarainitiative.org Subject: [Kantara - Community] Attributes from multiple APs
Hello everyone,
I am starting a thesis work on attributes management and aggregation in a federated identity environment and I am trying to figure out how to address attributes resolution in a scenario where there are multiple Attribute Providers. The main issue is: how does a relying party know which AP is responsible for a given attribute? As I am doing a research, I would like to know if in Kantara this problem has been faced and, if so, how you have solved it.
Thank you for your time and consideration.
Best Regards,
Mauro
-- Mauro L Polytechnic University of Turin _______________________________________________ Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
_______________________________________________ Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
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
Mauro, maybe you know about (Italian) ICAR project (INF-3) for the interoperability and cooperation for application among Regions. Piamonte Region (CSI) is the main editor for this spec. The specification includes a SAML 2.0 profile to manage an aggregation of attributes, using an user-centric approach. I hope it is useful for your research. Cheers. Domenico On Jan 9, 2012, at 6:30 PM, Mauro Levra wrote:
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
Hi Mauro, At User-Managed Access (UMA) WG, we explored some use-cases about attributes aggregation and third party attribute authority to provide a claim-based authorization system, that we call it Trusted Claims. Now, UMA protocol leverages Openid Connect specification for this specific interactions. Last December, Smart team at Newcastle Univ showed a basic UMA-Openid connect integration (demo) for this purpose. Here are some pointers: http://kantarainitiative.org/confluence/display/uma/loan_scenario http://identitycube.blogspot.com/2010/12/oauth-uma-and-enterprise.html http://identitycube.blogspot.com/2011/07/uma-openid-connect.html Domenico On Jan 3, 2012, at 7:43 PM, Mauro L <s172556@studenti.polito.it> wrote:
Hello everyone,
I am starting a thesis work on attributes management and aggregation in a federated identity environment and I am trying to figure out how to address attributes resolution in a scenario where there are multiple Attribute Providers. The main issue is: how does a relying party know which AP is responsible for a given attribute? As I am doing a research, I would like to know if in Kantara this problem has been faced and, if so, how you have solved it.
Thank you for your time and consideration.
Best Regards,
Mauro
-- Mauro L Polytechnic University of Turin _______________________________________________ Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
Mauro, Definitely take up Domenico's suggestions. You may also want to follow the effort of the Kantara Discussion Group on Attribute Management as we look at these issues as well. We are looking to define and address gaps in the current ability to manage attributes. http://kantarainitiative.org/confluence/display/AMDG/Home Regards, Sal -----Original Message----- From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Domenico Catalano Sent: Saturday, January 07, 2012 4:47 AM To: Mauro L Cc: UMA WG WG; community@kantarainitiative.org Subject: Re: [WG-UMA] [Kantara - Community] Attributes from multiple APs Hi Mauro, At User-Managed Access (UMA) WG, we explored some use-cases about attributes aggregation and third party attribute authority to provide a claim-based authorization system, that we call it Trusted Claims. Now, UMA protocol leverages Openid Connect specification for this specific interactions. Last December, Smart team at Newcastle Univ showed a basic UMA-Openid connect integration (demo) for this purpose. Here are some pointers: http://kantarainitiative.org/confluence/display/uma/loan_scenario http://identitycube.blogspot.com/2010/12/oauth-uma-and-enterprise.html http://identitycube.blogspot.com/2011/07/uma-openid-connect.html Domenico On Jan 3, 2012, at 7:43 PM, Mauro L <s172556@studenti.polito.it> wrote:
Hello everyone,
I am starting a thesis work on attributes management and aggregation in a federated identity environment and I am trying to figure out how to address attributes resolution in a scenario where there are multiple Attribute Providers. The main issue is: how does a relying party know which AP is responsible for a given attribute? As I am doing a research, I would like to know if in Kantara this problem has been faced and, if so, how you have solved it.
Thank you for your time and consideration.
Best Regards,
Mauro
-- Mauro L Polytechnic University of Turin _______________________________________________ Community mailing list Community@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/community
WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma
participants (8)
-
Colin Wallis -
Domenico Catalano -
Gerald Beuchelt -
Mauro L -
Mauro Levra
-
Nat Sakimura -
Patrick Curry -
Salvatore D'Agostino