I'm interested in contributing an answer: - I can't see any incentives for other providers to be "disintermediated" by a broker entity :-) An alternate model is to define the "broker" as a P2P network of nodes that must collaborate to maintain (their client's) data privacy. /thomas/ ________________________________________ From: wg-uma-bounces@kantarainitiative.org [wg-uma-bounces@kantarainitiative.org] on behalf of Adrian Gropper [agropper@healthurl.com] Sent: Saturday, October 24, 2015 11:27 AM To: Justin P Richer Cc: wg-uma@kantarainitiative.org UMA Subject: Re: [WG-UMA] NIST Seeks Comments on New Project Aimed at Protecting Privacy Online I'm interested in contributing to this comment and a session at IIW. Adrian On Sat, Oct 24, 2015 at 11:24 AM, Justin Richer mailto:jricher@mit.edu> wrote: My view on this remains “to increase privacy get rid of brokers”. A full mesh SAML or PKI federation is untenable, so that’s why we’ve deployed brokers in the past. But OIDC, with dynamic client registration and server discovery, is built for this. I believe wee need to move towards this model. Is anyone interested in writing up a response to that effect with me? Perhaps we could run a session on it at IIW this week for those of us that will be there (including myself). — Justin On Oct 23, 2015, at 8:29 AM, Andrew Hughes mailto:andrewhughes3000@gmail.com> wrote: Hi UMAnitarians - not sure if you've seen this notice yet I'm vice-chair of IAWG & we are probably going to assemble comments on this. "Privacy-Enhanced Identity Brokers" Comments to inform a new collaborative project & eventual 1800 series Practice Guide at the NIST NCCoE Due 18 December http://www.nist.gov/itl/acd/ncce/20151022privacy.cfm Andrew Hughes CISM CISSP Independent Consultant In Turn Information Management Consulting o +1 650.209.7542tel:%2B1%20650.209.7542 m +1 250.888.9474tel:%2B1%20250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.commailto:AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/http://ca.linkedin.com/pub/andrew-hughes/a/58/682/ Identity Management | IT Governance | Information Security _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma -- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

Justin, Is there a write-up of the solution you're proposing? Anyone, Can technology like the Bitcoin Hierarchical Deterministic Wallet enable an individual to act as their own identity broker? Adrian On Sat, Oct 24, 2015 at 11:38 AM, John Bradley wrote:

That is more or less my default position.

There may be times when it is more efficient for administrative reasons to proxy a group of RP via a gateway. In general gateways create more privacy issues than they solve.

It is probably worth discussing at IIW. I expect NIST will be raising the issue in the iGov WG as well.

John B.

On Oct 24, 2015, at 12:24 PM, Justin Richer wrote:

My view on this remains “to increase privacy get rid of brokers”. A full mesh SAML or PKI federation is untenable, so that’s why we’ve deployed brokers in the past. But OIDC, with dynamic client registration and server discovery, is built for this. I believe wee need to move towards this model.

Is anyone interested in writing up a response to that effect with me? Perhaps we could run a session on it at IIW this week for those of us that will be there (including myself).

— Justin

On Oct 23, 2015, at 8:29 AM, Andrew Hughes wrote:

Hi UMAnitarians - not sure if you've seen this notice yet

I'm vice-chair of IAWG & we are probably going to assemble comments on this.

"Privacy-Enhanced Identity Brokers"

Comments to inform a new collaborative project & eventual 1800 series Practice Guide at the NIST NCCoE

Due 18 December

http://www.nist.gov/itl/acd/ncce/20151022privacy.cfm

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/

Yes, that. Always looking at privacy from linkablility and anonymity perspectives. An Identity Broker with privacy in mind has the responsibility to protect those properties. Through policy, but also some funky cryptography could be applied to assist there. But yeah, in the end they have the potential to only make things worse from a privacy point of view, and not better. Cheers! Mark On 24/10/15 08:24, Justin Richer wrote:

My view on this remains “to increase privacy get rid of brokers”. A full mesh SAML or PKI federation is untenable, so that’s why we’ve deployed brokers in the past. But OIDC, with dynamic client registration and server discovery, is built for this. I believe wee need to move towards this model.

Is anyone interested in writing up a response to that effect with me? Perhaps we could run a session on it at IIW this week for those of us that will be there (including myself).

— Justin

...

On Oct 23, 2015, at 8:29 AM, Andrew Hughes mailto:andrewhughes3000@gmail.com> wrote:

Hi UMAnitarians - not sure if you've seen this notice yet

I'm vice-chair of IAWG & we are probably going to assemble comments on this.

"Privacy-Enhanced Identity Brokers"

Comments to inform a new collaborative project & eventual 1800 series Practice Guide at the NIST NCCoE

Due 18 December

http://www.nist.gov/itl/acd/ncce/20151022privacy.cfm

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 tel:%2B1%20650.209.7542 m +1 250.888.9474 tel:%2B1%20250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com mailto:AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ http://ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

A quick observation about this and other related threads: The NIST call for comment (and some of the responses I've seen so far) take quite an absolutist point of view. The particular example given by NIST: "Many organizations now allow online customers to use third-party credentials to create and manage accounts and services. For example, your social media account login can be used to access your fitness tracker account. In effect, the social media company is vouching for you with the tracker company." It's a mash of concerns and hinted-at fears and sets up what might be a false argument. Using a 'social account' to a consumer-driven 'fitness tracker' is not a good basis to argue for or against Credential Brokers, Gateways, fancy crypto blinding etc. Justin, John and others are highlighting what might be a typical pattern in technology adoption: the move from outlier/leading edge, to brokered solutions to multiply visibility and increase ease of market penetration, to discovery aggregators to peer-to-peer oriented connection finders. (Please don't pick on the list - it's an extemporaneous sample). So: should we be attempting to treat some of the concerns somewhat independently? a) The wish to move to person-selected authentication/identity providers for easing multi-credential burden b) The need for discovery, marketing and publication services to increase market penetration c) The desire to offer unobservability and non-linkability properties to those who need or want them d) The need to remove brokers/gateways when appropriate e) The wish to defeat large scale analytics-based profiling Reactions? andrew. *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* o +1 650.209.7542 m +1 250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security * On Wed, Oct 28, 2015 at 11:23 PM, Eve Maler wrote:

Okay, I’ll be the contrarian, just for fun.

As I commented to a couple of people regarding the relatively recent academic paper Toward Mending Two Nation-Scale Brokered Identification Systems http://www0.cs.ucl.ac.uk/staff/G.Danezis/papers/popets15-brokid.pdf, everything is tradeoffs. And it’s arguable that the governments in those cases made the operationally and more citizen-acceptable tradeoff for privacy vs. what the researchers recommended.

Quoting/paraphrasing myself from previous threads on this topic:

I suspected from a brief article http://www.computing.co.uk/ctg/news/2414194/govuk-verify-identity-management... on the subject that the reporter probably had trouble divining exactly what the problem with the FCCX and UK.Gov http://uk.gov Verify systems actually was, since it wasn't explained at all, nor what the proposed solution was... and it's all extremely subtle. And I'm not even seeing a huge outcry or even all that much gov followup/panicked defense after.

The researchers found a limitation in the tradeoff choice that the FCCX and UK.Gov http://uk.gov Verify system designers made. This tradeoff prizes the ability for the user to use an online service ("relying party") and an identity provider, free from worrying that the two will discover who the other is, over the perfect ability for a pseudonymous identifier and attributes representing the user to pass unseen through the broker in the middle (the broker makes this "service blinding" possible). The researchers propose some clever encryption tricks to guard against the broker seeing things, and go further and propose a new user-chosen "identity integration" service that could handle the tricks. Given that brokered systems, and the "older" protocols such as SAML already in use, and the encryption tricks they suggest, and user interfaces that force users to choose services, are all considered extremely heavyweight and expensive in various ways, I give the researchers' suggestions a nil chance of succeeding in the current environment. And given that users have a variety of incentives to share enough attributes in everyday circumstances to routinely become identifiable (Latanya Sweeney's research in particular is famous for discovering these properties), it's very questionable whether the researchers' preference for tradeoffs vs. the nations' preference is the correct one.

On 25 Oct 2015, at 7:49 AM, Mark Dobrinic wrote:

Yes, that.

Always looking at privacy from linkablility and anonymity perspectives. An Identity Broker with privacy in mind has the responsibility to protect those properties. Through policy, but also some funky cryptography could be applied to assist there.

But yeah, in the end they have the potential to only make things worse from a privacy point of view, and not better.

Cheers!

Mark

On 24/10/15 08:24, Justin Richer wrote:

My view on this remains “to increase privacy get rid of brokers”. A full mesh SAML or PKI federation is untenable, so that’s why we’ve deployed brokers in the past. But OIDC, with dynamic client registration and server discovery, is built for this. I believe wee need to move towards this model.

Is anyone interested in writing up a response to that effect with me? Perhaps we could run a session on it at IIW this week for those of us that will be there (including myself).

— Justin

On Oct 23, 2015, at 8:29 AM, Andrew Hughes >> wrote:

Hi UMAnitarians - not sure if you've seen this notice yet

I'm vice-chair of IAWG & we are probably going to assemble comments on this.

"Privacy-Enhanced Identity Brokers"

Comments to inform a new collaborative project & eventual 1800 series Practice Guide at the NIST NCCoE

Due 18 December

http://www.nist.gov/itl/acd/ncce/20151022privacy.cfm

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 tel:%2B1%20650.209.7542 m +1 250.888.9474 tel:%2B1%20250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com mailto:AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ http://ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

Eve, I agree with your viewpoint. In general, we find in our customer interactions that there are at least five key tradeoffs to consider in broker identity federation: 1. Security 2. Privacy 3. User Experience 4. Cost 5. Liability In math terms, these constraints could be considered the boundaries of a non-linear solution space where a relying party may want adjust each tradeoff to "optimize" their transaction process. And, depending upon the purpose of the relying party web site/service and the target user constituency, the optimization of these tradeoffs can vary significantly. For example, consumer facing web sites for purposes of information exposure may want to allow a social credential login with little or no requirements for attribute verification. However a B2B supply chain application for partner employees, vendors and suppliers may require strong multi-factor authentication plus contextual attribute verification (e.g., active employment status, clearance, etc.). In the case of FCCX, the desire for stronger privacy controls may challenge the security policy and risk mitigation requirements of participating relying parties, and can thereby result in a liability distribution model that does not scale and is untenable in the market. As such, a business model cannot thrive that recognizes the diverse needs of each relying party service provider to deliver services with fungible contract mechanisms in a competitive environment. This will drive away interest and participation from key service providers due to non-compliance with their operating and insurance policies. As privacy policy continues to evolve into legislative requirements, the tradeoffs listed above will likely be some of the key components of the debate. The argument of "one size fits all" will not likely prevail given the diversity of requirements and stakeholders. A more reasonable approach might be for identity broker services to enable relying party choice with tools that allow trust framework communities to define the rules for how the tools are deployed. The combination of privacy enhancing capabilities (tools), consumer trends, legislative pressures, technology evolution, and competitive market forces will likely be the key drivers of change and ultimately drive continuous evolution of the optimal solution set for any relying party. Regards, Dave David Coxe, CEO ID/DataWeb, Inc. DCoxe@IDDataWeb.commailto:DCoxe@IDDataWeb.com 571-332-2740 cell 703-942-5800, ext 315 office From: wg-uma-bounces@kantarainitiative.org [mailto:wg-uma-bounces@kantarainitiative.org] On Behalf Of Eve Maler Sent: Thursday, October 29, 2015 2:24 AM To: Mark Dobrinic Cc: wg-uma@kantarainitiative.org UMA Subject: Re: [WG-UMA] NIST Seeks Comments on New Project Aimed at Protecting Privacy Online Okay, I'll be the contrarian, just for fun. As I commented to a couple of people regarding the relatively recent academic paper Toward Mending Two Nation-Scale Brokered Identification Systemshttp://www0.cs.ucl.ac.uk/staff/G.Danezis/papers/popets15-brokid.pdf, everything is tradeoffs. And it's arguable that the governments in those cases made the operationally and more citizen-acceptable tradeoff for privacy vs. what the researchers recommended. Quoting/paraphrasing myself from previous threads on this topic: I suspected from a brief articlehttp://www.computing.co.uk/ctg/news/2414194/govuk-verify-identity-management... on the subject that the reporter probably had trouble divining exactly what the problem with the FCCX and UK.Govhttp://uk.gov Verify systems actually was, since it wasn't explained at all, nor what the proposed solution was... and it's all extremely subtle. And I'm not even seeing a huge outcry or even all that much gov followup/panicked defense after. The researchers found a limitation in the tradeoff choice that the FCCX and UK.Govhttp://uk.gov Verify system designers made. This tradeoff prizes the ability for the user to use an online service ("relying party") and an identity provider, free from worrying that the two will discover who the other is, over the perfect ability for a pseudonymous identifier and attributes representing the user to pass unseen through the broker in the middle (the broker makes this "service blinding" possible). The researchers propose some clever encryption tricks to guard against the broker seeing things, and go further and propose a new user-chosen "identity integration" service that could handle the tricks. Given that brokered systems, and the "older" protocols such as SAML already in use, and the encryption tricks they suggest, and user interfaces that force users to choose services, are all considered extremely heavyweight and expensive in various ways, I give the researchers' suggestions a nil chance of succeeding in the current environment. And given that users have a variety of incentives to share enough attributes in everyday circumstances to routinely become identifiable (Latanya Sweeney's research in particular is famous for discovering these properties), it's very questionable whether the researchers' preference for tradeoffs vs. the nations' preference is the correct one. On 25 Oct 2015, at 7:49 AM, Mark Dobrinic mailto:mdobrinic@cozmanova.com> wrote: Yes, that. Always looking at privacy from linkablility and anonymity perspectives. An Identity Broker with privacy in mind has the responsibility to protect those properties. Through policy, but also some funky cryptography could be applied to assist there. But yeah, in the end they have the potential to only make things worse from a privacy point of view, and not better. Cheers! Mark On 24/10/15 08:24, Justin Richer wrote: My view on this remains "to increase privacy get rid of brokers". A full mesh SAML or PKI federation is untenable, so that's why we've deployed brokers in the past. But OIDC, with dynamic client registration and server discovery, is built for this. I believe wee need to move towards this model. Is anyone interested in writing up a response to that effect with me? Perhaps we could run a session on it at IIW this week for those of us that will be there (including myself). - Justin On Oct 23, 2015, at 8:29 AM, Andrew Hughes mailto:andrewhughes3000@gmail.com mailto:andrewhughes3000@gmail.com> wrote: Hi UMAnitarians - not sure if you've seen this notice yet I'm vice-chair of IAWG & we are probably going to assemble comments on this. "Privacy-Enhanced Identity Brokers" Comments to inform a new collaborative project & eventual 1800 series Practice Guide at the NIST NCCoE Due 18 December http://www.nist.gov/itl/acd/ncce/20151022privacy.cfm *Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting* o +1 650.209.7542 tel:%2B1%20650.209.7542 m +1 250.888.9474 tel:%2B1%20250.888.9474 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.commailto:AndrewHughes3000@gmail.com mailto:AndrewHughes3000@gmail.com ca.linkedin.com/pub/andrew-hughes/a/58/682/ http://ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security * _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org mailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma _______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.orgmailto:WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.commailto:xmlgrrl@gmail.com

If we don't take the privacy engineering approach today, we will need to do it tomorrow. Specifically, we (OIDC, UMA, HEART, IDESG) need to give ROs a standard way of registering for service APIs with pairwise pseudonymity and then passing verified attributes only as needed. If that can be done without identity brokers, that's fine with me. Adrian On Thu, Oct 29, 2015 at 10:40 AM, Eve Maler wrote:

Beautifully put! And thanks to Andrew for putting his finger on the thing that was bothering me about their request!

Eve (from my iPad)

On Oct 29, 2015, at 5:21 AM, Dave Coxe ID wrote:

Eve,

I agree with your viewpoint. In general, we find in our customer interactions that there are at least five key tradeoffs to consider in broker identity federation:

1. Security

2. Privacy

3. User Experience

4. Cost

5. Liability

In math terms, these constraints could be considered the boundaries of a non-linear solution space where a relying party may want adjust each tradeoff to “optimize” their transaction process. And, depending upon the purpose of the relying party web site/service and the target user constituency, the optimization of these tradeoffs can vary significantly. For example, consumer facing web sites for purposes of information exposure may want to allow a social credential login with little or no requirements for attribute verification. However a B2B supply chain application for partner employees, vendors and suppliers may require strong multi-factor authentication plus contextual attribute verification (e.g., active employment status, clearance, etc.).

In the case of FCCX, the desire for stronger privacy controls may challenge the security policy and risk mitigation requirements of participating relying parties, and can thereby result in a liability distribution model that does not scale and is untenable in the market. As such, a business model cannot thrive that recognizes the diverse needs of each relying party service provider to deliver services with fungible contract mechanisms in a competitive environment. This will drive away interest and participation from key service providers due to non-compliance with their operating and insurance policies.

As privacy policy continues to evolve into legislative requirements, the tradeoffs listed above will likely be some of the key components of the debate. The argument of “one size fits all” will not likely prevail given the diversity of requirements and stakeholders. A more reasonable approach might be for identity broker services to enable relying party choice with tools that allow trust framework communities to define the rules for how the tools are deployed. The combination of privacy enhancing capabilities (tools), consumer trends, legislative pressures, technology evolution, and competitive market forces will likely be the key drivers of change and ultimately drive continuous evolution of the optimal solution set for any relying party.

Regards,

Dave

David Coxe, CEO

ID/DataWeb, Inc.

DCoxe@IDDataWeb.com

571-332-2740 cell

703-942-5800, ext 315 office

*From:* wg-uma-bounces@kantarainitiative.org [ mailto:wg-uma-bounces@kantarainitiative.org ] *On Behalf Of *Eve Maler *Sent:* Thursday, October 29, 2015 2:24 AM *To:* Mark Dobrinic *Cc:* wg-uma@kantarainitiative.org UMA *Subject:* Re: [WG-UMA] NIST Seeks Comments on New Project Aimed at Protecting Privacy Online

Okay, I’ll be the contrarian, just for fun.

As I commented to a couple of people regarding the relatively recent academic paper Toward Mending Two Nation-Scale Brokered Identification Systems http://www0.cs.ucl.ac.uk/staff/G.Danezis/papers/popets15-brokid.pdf, everything is tradeoffs. And it’s arguable that the governments in those cases made the operationally and more citizen-acceptable tradeoff for privacy vs. what the researchers recommended.

Quoting/paraphrasing myself from previous threads on this topic:

I suspected from a brief article http://www.computing.co.uk/ctg/news/2414194/govuk-verify-identity-management... on the subject that the reporter probably had trouble divining exactly what the problem with the FCCX and UK.Gov http://uk.gov Verify systems actually was, since it wasn't explained at all, nor what the proposed solution was... and it's all extremely subtle. And I'm not even seeing a huge outcry or even all that much gov followup/panicked defense after.

The researchers found a limitation in the tradeoff choice that the FCCX and UK.Gov http://uk.gov Verify system designers made. This tradeoff prizes the ability for the user to use an online service ("relying party") and an identity provider, free from worrying that the two will discover who the other is, over the perfect ability for a pseudonymous identifier and attributes representing the user to pass unseen through the broker in the middle (the broker makes this "service blinding" possible). The researchers propose some clever encryption tricks to guard against the broker seeing things, and go further and propose a new user-chosen "identity integration" service that could handle the tricks. Given that brokered systems, and the "older" protocols such as SAML already in use, and the encryption tricks they suggest, and user interfaces that force users to choose services, are all considered extremely heavyweight and expensive in various ways, I give the researchers' suggestions a nil chance of succeeding in the current environment. And given that users have a variety of incentives to share enough attributes in everyday circumstances to routinely become identifiable (Latanya Sweeney's research in particular is famous for discovering these properties), it's very questionable whether the researchers' preference for tradeoffs vs. the nations' preference is the correct one.

On 25 Oct 2015, at 7:49 AM, Mark Dobrinic wrote:

Yes, that.

Always looking at privacy from linkablility and anonymity perspectives. An Identity Broker with privacy in mind has the responsibility to protect those properties. Through policy, but also some funky cryptography could be applied to assist there.

But yeah, in the end they have the potential to only make things worse from a privacy point of view, and not better.

Cheers!

Mark

On 24/10/15 08:24, Justin Richer wrote:

My view on this remains “to increase privacy get rid of brokers”. A full mesh SAML or PKI federation is untenable, so that’s why we’ve deployed brokers in the past. But OIDC, with dynamic client registration and server discovery, is built for this. I believe wee need to move towards this model.

Is anyone interested in writing up a response to that effect with me? Perhaps we could run a session on it at IIW this week for those of us that will be there (including myself).

— Justin

On Oct 23, 2015, at 8:29 AM, Andrew Hughes >> wrote:

Hi UMAnitarians - not sure if you've seen this notice yet

I'm vice-chair of IAWG & we are probably going to assemble comments on this.

"Privacy-Enhanced Identity Brokers"

Comments to inform a new collaborative project & eventual 1800 series Practice Guide at the NIST NCCoE

Due 18 December

http://www.nist.gov/itl/acd/ncce/20151022privacy.cfm

*Andrew Hughes *CISM CISSP Independent Consultant *In Turn Information Management Consulting*

o +1 650.209.7542 > m +1 250.888.9474 > 1249 Palmer Road, Victoria, BC V8P 2H8 AndrewHughes3000@gmail.com > ca.linkedin.com/pub/andrew-hughes/a/58/682/ http://ca.linkedin.com/pub/andrew-hughes/a/58/682/ *Identity Management | IT Governance | Information Security *

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org > http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

Eve Maler | cell +1 425.345.6756 | Skype: xmlgrrl | Twitter: @xmlgrrl | Calendar: xmlgrrl@gmail.com

_______________________________________________ WG-UMA mailing list WG-UMA@kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-uma

-- Adrian Gropper MD PROTECT YOUR FUTURE - RESTORE Health Privacy! HELP us fight for the right to control personal health data. DONATE: http://patientprivacyrights.org/donate-2/