[DG-NSTIC] Short Summary of DC Relying Party party (was) Re: Colin Wallis has sent you a message from FierceGovernmentIT
9 views
Skip to first unread message
Joni Brennan
May 30, 2012, 11:01:13 AM5/30/12
to dg-n...@kantarainitiative.org
Since many are interested I thought I'd give a short summary of the RP event in DC last week.
A meeting took place in Washington DC last which which was basically a "Relying Party party". A focused group of top level US company CIOs attended. The intent for the meeting was to communicate the vision of NSTIC, why it's important and why RPs should become involved in the NSTIC steering group.
The group heard from representatives including: the NSTIC NPO, Director of NIST, UK ID Assurance lead, a Senate Representative as well as a panel of experts from sectors including: analyst, financial services, sales services, payment services and health care.
The panel made compelling cases for why a trusted identity ecosystem (in the US) is needed and why it would bring value and cost savings to organizations. One particular message of interest was - don't be an IdP if you don't need to be. Orgs were encouraged to review their own identity systems to understand how much they are spending and how much they could save by using trusted CSPs rather than 'build your own' id systems.
~25 orgs noted their support of the NSTIC program. In closing, It was a great to see some new organizations coming to the 'party'. We'll know more regarding the NSTIC Secretariat in the next few weeks.
That said this group - has work cut out to develop a paper explaining how Kantara would seek to interface with the NISTIC SG. I have an action to write a first draft of that paper. With a lighter call load today I will seek to progress.
Thanks,
=Joni
Joni Brennan
Kantara Initiative | Executive Director
voice:+1 732-226-4223
email: joni @ ieee-isto.org
Slideshare - Building Trusted Identity Ecosystems - It takes a village!
http://www.slideshare.net/kantarainitiative/kantara-may-2012
A meeting took place in Washington DC last which which was basically a "Relying Party party". A focused group of top level US company CIOs attended. The intent for the meeting was to communicate the vision of NSTIC, why it's important and why RPs should become involved in the NSTIC steering group.
The group heard from representatives including: the NSTIC NPO, Director of NIST, UK ID Assurance lead, a Senate Representative as well as a panel of experts from sectors including: analyst, financial services, sales services, payment services and health care.
The panel made compelling cases for why a trusted identity ecosystem (in the US) is needed and why it would bring value and cost savings to organizations. One particular message of interest was - don't be an IdP if you don't need to be. Orgs were encouraged to review their own identity systems to understand how much they are spending and how much they could save by using trusted CSPs rather than 'build your own' id systems.
~25 orgs noted their support of the NSTIC program. In closing, It was a great to see some new organizations coming to the 'party'. We'll know more regarding the NSTIC Secretariat in the next few weeks.
That said this group - has work cut out to develop a paper explaining how Kantara would seek to interface with the NISTIC SG. I have an action to write a first draft of that paper. With a lighter call load today I will seek to progress.
Thanks,
=Joni
Joni Brennan
Kantara Initiative | Executive Director
voice:+1 732-226-4223
email: joni @ ieee-isto.org
Slideshare - Building Trusted Identity Ecosystems - It takes a village!
http://www.slideshare.net/kantarainitiative/kantara-may-2012
On Wed, May 30, 2012 at 5:57 AM, Joni Brennan <jo...@ieee-isto.org> wrote:
I hadn't seen it yet but the content is in line with our Kantara culture - absolutely. More data point. Went to an interesting meeting last week in DC for RPs ... where NSTIC was "selling" them on joining the NSTIC efforts. I can tell you more off email.
thx,
=Joni
Joni Brennan
Kantara Initiative | Executive Director
voice:+1 732-226-4223
email: joni @ ieee-isto.org
Slideshare - Building Trusted Identity Ecosystems - It takes a village!
http://www.slideshare.net/kantarainitiative/kantara-may-2012
On Tue, May 29, 2012 at 8:48 PM, Colin Wallis <nor...@fiercegovernmentit.com> wrote:
_______________________________________________
FierceGovernmentIT
Colin Wallis thought you would like to see the FierceGovernmentIT web site. Message from Sender
FYI
Is this old news to everyone except me (still trawling his overloaded email box)?Cyber threat sharing needs guarantees, says Rand researcher
by dperera
The information sharing effort studies by Rand involved European telecommunication firms operating under a model whereby government involvement was limited to acting as a neutral third party provider of an information sharing platform. Essentially, he said, the public sector provided a meeting room but little more.
DG-NSTIC mailing list
DG-N...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/dg-nstic
Salvatore D'Agostino
May 30, 2012, 11:33:51 AM5/30/12
to Joni Brennan, dg-n...@kantarainitiative.org
Thanks Joni, great update. Look forward to ideas about SG.
Bob Pinheiro
May 30, 2012, 1:59:42 PM5/30/12
to dg-n...@kantarainitiative.org, Francisco Corella
Should an organization build its own identity system, versus relying
on a trusted identity ecosystem? The concept of an identity
provider is built into NSTIC and the identity ecosystem idea, as
well as the Kantara Trust Framework. But I think there are
situations, such as those involving routine, ongoing authentication
to protected resources, where involvement of a third party IdP
should not be needed.
Identity federation between business partners is not new, and many businesses employ federation so that employees of one organization, once logged into their in-house systems, do not need to re-authenticate themselves to access the systems of their business partners. This is the classic single sign-on use case. I suppose a case can be made that these organizations could rely on external IdPs for authenticating their own employees, and for federation with business partners.
But in my opinion, the truly interesting federation problem involves public-facing, high-value services for individuals / consumers in which there is significant risk of harm when mis-identification occurs. When someone unknown to the service provider seeks to enroll in such a service, there is considerable advantage to being able to rely on an assertion from a trusted third party to establish that new relationship. But once enrolled, why should these service providers continue to depend on assertions from third party identity providers for routine, ongoing customer access to these services? There is a cost and availability issue to consider: these SPs may need to pay something to the IdP for these authentications, and there is always the possibility that the IdP will be unavailable, thereby preventing customers from accessing their services. And then there is the privacy issue - these IdPs will know which services users are accessing, and when they are doing so.
There certainly are use cases where involvement of an IdP may be needed each time someone uses a service. For instance, NSTIC might support the notion of tokenized credit card payments. Instead of providing a credit card number to an online merchant, a virtual credit card number is generated by a bank acting as an IdP. This virtual cc number may only be valid for a specific merchant for a short period of time, or only for a single transaction. And a trusted IdP can assert someone's identity to a RP for the purpose of establishing a new high-value relationship, or when critical attribute values change and must be known to the service provider. But in many other cases, I think it is worth exploring ways in which RPs could authenticate their customers for ongoing access to their services without needing to involve an IdP every time.
SSL / TLS was designed to provide a secure channel between service providers and their users for conducting online transactions, as well as for providing mutual authentication of service providers and users. But while it has succeeded in achieving the first goal, it has largely failed in the second, especially as regards the use of client-side certificates for authentication of users to service providers. As Francisco Corella of Pomcor has suggested, client-side certificates could be issued by RPs directly to their users via TLS by means of new issuance protocols. These "login certificates" could then be used for strong authentication of the user to the service provider, without requiring the involvement of a third party identity provider.
Alternatively (and perhaps more in synch with Kantara's mission), trust frameworks could be defined to allow users to "bring your own credential" to the service provider. An NSTIC-compliant identity ecosystem might therefore enable multiple SPs / RPs to trust a PKI certificate that a user already possesses, so that it may be bound to these services for ongoing authentication.
I'm not sure what it means for Kantara to interface with NSTIC, other than to have a place on the NSTIC Steering Group. Should Kantara adopt, and advocate for, certain positions or policies as a member of the Steering Group? For instance, would Kantara, through this DG, agree with some of the positions stated above? If not, would / should the DG advocate for other positions?
Identity federation between business partners is not new, and many businesses employ federation so that employees of one organization, once logged into their in-house systems, do not need to re-authenticate themselves to access the systems of their business partners. This is the classic single sign-on use case. I suppose a case can be made that these organizations could rely on external IdPs for authenticating their own employees, and for federation with business partners.
But in my opinion, the truly interesting federation problem involves public-facing, high-value services for individuals / consumers in which there is significant risk of harm when mis-identification occurs. When someone unknown to the service provider seeks to enroll in such a service, there is considerable advantage to being able to rely on an assertion from a trusted third party to establish that new relationship. But once enrolled, why should these service providers continue to depend on assertions from third party identity providers for routine, ongoing customer access to these services? There is a cost and availability issue to consider: these SPs may need to pay something to the IdP for these authentications, and there is always the possibility that the IdP will be unavailable, thereby preventing customers from accessing their services. And then there is the privacy issue - these IdPs will know which services users are accessing, and when they are doing so.
There certainly are use cases where involvement of an IdP may be needed each time someone uses a service. For instance, NSTIC might support the notion of tokenized credit card payments. Instead of providing a credit card number to an online merchant, a virtual credit card number is generated by a bank acting as an IdP. This virtual cc number may only be valid for a specific merchant for a short period of time, or only for a single transaction. And a trusted IdP can assert someone's identity to a RP for the purpose of establishing a new high-value relationship, or when critical attribute values change and must be known to the service provider. But in many other cases, I think it is worth exploring ways in which RPs could authenticate their customers for ongoing access to their services without needing to involve an IdP every time.
SSL / TLS was designed to provide a secure channel between service providers and their users for conducting online transactions, as well as for providing mutual authentication of service providers and users. But while it has succeeded in achieving the first goal, it has largely failed in the second, especially as regards the use of client-side certificates for authentication of users to service providers. As Francisco Corella of Pomcor has suggested, client-side certificates could be issued by RPs directly to their users via TLS by means of new issuance protocols. These "login certificates" could then be used for strong authentication of the user to the service provider, without requiring the involvement of a third party identity provider.
Alternatively (and perhaps more in synch with Kantara's mission), trust frameworks could be defined to allow users to "bring your own credential" to the service provider. An NSTIC-compliant identity ecosystem might therefore enable multiple SPs / RPs to trust a PKI certificate that a user already possesses, so that it may be bound to these services for ongoing authentication.
I'm not sure what it means for Kantara to interface with NSTIC, other than to have a place on the NSTIC Steering Group. Should Kantara adopt, and advocate for, certain positions or policies as a member of the Steering Group? For instance, would Kantara, through this DG, agree with some of the positions stated above? If not, would / should the DG advocate for other positions?
--------------------------- Bob Pinheiro Chair, Consumer Identity WG 908-654-1939 kan...@bobpinheiro.com www.bobpinheiro.com
Reply all
Reply to author
Forward
0 new messages