IIW - User contributions [en]

Main Page

2020-01-03T13:43:39Z

WikiSysop: Reverted edits by Reno (talk) to last revision by Nobnatu

<Big> Welcome to the Internet Identity Workshop (IIW) Wiki </big>

[http://www.internetidentityworkshop.com WE HAVE A WEBSITE/BLOG TOO!]

* To get updates regarding IIW [http://lists.idcommons.net/lists/subscribe/iiwinfo subscribe here].

* To join the identity commons community list and dialoguing about user-centric and other identity initiatives [http://lists.idcommons.net/lists/subscribe/community you can do so here].

* To learn more about identity commons linking together efforts and supporting innovation in user-centric digital identity [http://www.idcommons.net/ visit the website]

=== Next Internet Identity Workshops ===

*'''IIW 30 is April 28, 29 & 30, 2020
**'''[[IIW 30 Proposed Topics]]'''
**'''[[IIW 30 Demo Hour]]'''
**'''[[IIW 30 Tech Sandbox Breakfast Fair]]'''
**'''[[IIW 30 Session Notes]]'''
**'''[[IIW 30 Notes Format and Process]]'''

*'''IIW 31 is October 20, 21, & 22, 2020

=== Previous Internet Identity Workshops & Satellite Events ===
*'''IIW 29 was October 1, 2 & 3, 2019
**'''[[IIW 29 Proposed Topics]]'''
**'''[[IIW 29 Demo Hour]]'''
**'''[[IIW 29 Tech Sandbox Breakfast Fair]]'''
**'''[[IIW 29 Session Notes]]'''
**'''[[Note Format and Process]]'''

*'''IIW 28 was April 30 - May 1 & 2 , 2019
**'''[[IIW 28 Proposed Topics]]'''
**'''[[IIW 28 Demo Hour]]'''
**'''[[IIW 28 Tech Sandbox Breakfast Fair]]'''
**'''[[IIW 28 Session Notes]]'''
**'''[[Note Format and Process]]'''

*'''IIW 27 was October 23 - 25 , 2018'''
**'''[[IIW 27 Proposed Topics]]'''
**'''[[IIW 27 Demo Hour]]'''
**'''[[IIW 27 Tech Sandbox Breakfast Fair]]'''
**'''[[IIW 27 Session Notes]]'''
**'''[[Note Format and Process]]'''

*'''IIW 26 was April 3 -5 , 2018'''
**'''[[IIW 26 Proposed Topics]]'''
**'''[[IIW 26 Demo's]]'''
**'''[[IIW 26 Session Notes]]'''
**'''[[Note Form]]'''

*'''IIW 25 was October 17 - 19, 2017'''
**'''[[IIW 25 Proposed Topics]]'''
**'''[[IIW 25 Demo's]]'''
**'''[[IIW 25 Session Notes]]'''
**'''[[Note Form]]'''

*'''IIW 24 was May 2-4, 2017'''
**'''[[IIW 24 Proposed Topics]]'''
**'''[[IIW 24 Demo's]]'''
**'''[[IIW 24 Session Notes]]'''
**'''[[Note Form]]'''

*'''IIW 23 October 25-27, 2016'''
**[[IIW 23 Proposed Topics]]
**[[IIW 23 Demo's]]
**[[IIW 23 Notes]]
**[[Note Form]]

*'''Verifiable Claims Face-to-Face is October 27-28, 2016''' (hosted at IIW 23)
**[https://docs.google.com/document/d/1uYDRcHs_EOpJzezJerKnKT4Grni1sFLX2nRp7zlq2BE/edit# Verifiable Claims Face-to-Face Agenda]
**[http://w3c.github.io/vctf/meetings/2016-10-27/ Verifiable Claims Meeting Minutes from Day One]
**[http://w3c.github.io/vctf/meetings/2016-10-28/ Verifiable Claims Meeting Minutes from Day Two]

*'''IIW 22 April 26 - 28, 2016'''
**[[IIW 22 Proposed Topics]]
**[[IIW 22 Demo's]]
**[[IIW 22 Notes]]
**[[Note Form]]

* '''IIW 21 October 27-29, 2015'''
**[[IIW 21 Proposed Topics]]
**[[IIW 21 Demo's]]
**[[IIW 21 Notes]]
**[[Note Form]]

* '''IIW 20 April 7 - 9, 2015'''
** [[IIW 20 Proposed Topics]]
** [[IIW 20 Demo's]]
** [[IIW 20 Notes]]
** [http://iiw.idcommons.net/images/1/10/IIWXX_Book_of_Proceedings_20_forWiki_less_photos.pdf ‎ IIW20 Book of Proceedings]

* '''IIW 19 October 28-30, 2014'''
** [[IIW 19 Proposed Topics]]
** [[IIW 19 Notes]]
** [http://iiw.idcommons.net/images/8/8a/IIWXIX_Book_of_Proceedings_19_CMPRSD.pdf IIW19 Book of Proceedings]

* '''IIW 18 May 6-8, 2014'''
**[[IIW 18 Proposed Topics]]
**[[IIW 18 Notes]]
**[http://iiw.idcommons.net/images/6/61/IIWXVIII_-18_Book_of_Proceedings_a.pdf IIW18 Book of Proceedings]

* '''IIW 17 October 22-24, 2013'''
** [[IIW 17 Proposed Topics]]
** [[IIW 17 Notes]]
** [http://iiw.idcommons.net/File:IIW17_BookofProceedings_2103B.pdf IIW17 Book of Proceedings]

* '''IIW #16 May 7-9 2013
** [[IIW 16 Proposed Topics]]
** [[IIW 16 Notes]]
** [http://iiw.idcommons.net/images/1/13/IIW16_Book_of_Proceedings.PDF IIW 16 Book of Proceedings]

* '''IIW #15 October 23-25 2012'''
** [[IIW 15 Proposed Topics]]
** [[IIW 15 Notes]]
** [http://iiw.idcommons.net/File:IIW15_Book_of_Proceedings.pdf IIW 15 Book of Proceedings]

* '''IIW #14 May 1-3 2012'''
**[[IIW 14 Proposed Topics]]
**[[IIW 14 Notes]]
**[http://iiw.idcommons.net/images/5/51/IIW14_BOP_PDF.pdf IIW 14 Book of Proceedings]

* IIW-Satellite Sydney
** [[IIW Satellite Sydney Notes]]

* IIW-Satelite DC
** [http://iiwsatellitedc2012.eventbrite.com/ Attendee List]
** [[IIW Satelite DC Proposed Topics]]
** [[IIW Satellite DC Notes]]

* IIW #13 October 18-20 2011
** [[iiw13 Proposed Topics]]
** [[IIW 13 Notes]]
** [["NSTIC Day" Proposed Agenda]]
** [[http://iiw.idcommons.net/File:IIW13_BOP_PDF.pdf IIW 13 Book of Proceedings]]

* IIW #12 May 3-5, 2011 at the Computer History Museum in Mountain View California
** [[iiw12 Proposed Topics]]
** [[IIW 12 Notes]]

* Identity Collaboration Day, Feb 14, 2011 - Day before RSA, for discussion of user-centric, enterprise and government identity initiatives.
** [http://www.idcolab.eventbrite.com ID Collaboration Day Registration/Description]
** [[IDCollab Proposed Topics]]
** [[IDCollab Day Notes]]

* IIW #11 Fall 2010 [[iiw11]] Nov 2-4, Tuesday-Thursday at the Computer HIstory Museum in Mountain View California
** [[Notes IIW11]]
** [http://www.internetidentityworkshop.com/what-is-iiw/ Responses to IIW is...] [http://bit.ly/dt3ruz Values of IIW]

* [[iiw-europe-1|IIW Europe]] in London Monday October 11 (before RSA Europe) at the University of London
** [[iiw-europe-1-Notes]]
** [[iiw-europe-1-Reflection]] As a Result of Today....

* [[iiw-east-1|IIW East Coast]] in DC September 9-10 Thursday, Friday at the Josephine Butler Parks Center (following the Gov 2.0 Summit) the theme will be ''Open Identity for Open Government''
** [[Notes_IIW-East]]
** [[As a result of day 1 at IIW-East]]

* #10: Spring 2010 [[iiw10]] May 17-19 at the Computer History Museum.
** [[Notes IIW10]]

* #9: Fall 2009 [[iiw9]] TUESDAY November 3 to THURSDAY November 5.
** [[Notes_iiw9]]

* #8: Spring 2009 [[iiw8]] - '''May 18-20, 2009'''
** [[Notes_iiw8]]

* #7: Fall [[iiw2008b]] (2008B)- '''Nov 10-12''' - Computer History Museum, Mountain View, CA
** [[Notes_08b]]

* 6: Spring [[iiw2008a]] (2008A)- '''May 12-14, 2008''' - Computer History Museum, Mountain View, CA
** [[Notes_2008a]]

* [http://iiw.idcommons.net/index.php/Iiw2007b 5: December 3-5, 2007 - Computer History Museum, Mountain View, CA]

* [http://iiw.windley.com/wiki/Workshop_2007 4: May 2007 - Computer History Museum, Mountain View, CA]

* [http://iiw.windley.com/wiki/Workshop2006b 3: December 2006 - Computer History Museum, Mountain View, CA]

* [http://iiw.windley.com/wiki/Workshop2006 2: May 2006 - - Computer History Museum, Mountain View, CA]

* [http://www.socialtext.net/iiw2005/index.cgi?internet_identity_workshop_2005 1: October 2005 - Berkeley, CA]

=== Previous Identity Open Spaces ===

Identity Open Space events are co-produced by the IIW team (Phil, Kaliya, Doc) in collaboration with other organizations and events. To date we have worked with Digital Identity World and the Liberty Alliance. [http://www.grabcasinobonus.com/casino-bonuses/ Mobile Casino Bonus] We are open to working with a variety organizations - if you are interested please don't hesitate to contact us. [http://ios.windley.com/wiki/IOSSF September 2007 at Digital Identity World]

[http://ios.windley.com/wiki/IOSBrussels May 2007 following a Liberty Alliance Meeting in Brussels, Belgium]

[http://ios.windley.com/wiki/IOSSantaClara September 2006 at Digital Identity World]

=== Previous Identity Birds of a Feather Meetings ===

June 2006 [http://www.identitygang.org/ Identity Gang Birds of a Feather Session] at Burton Group Conference, San Francisco

January 2006 [http://www.socialtext.net/iiw2005/index.cgi?identity_speed_geeking_o_reilly_emerging_telephony_conference Identity Speed Geeking Session] at O'Reilly's Emerging Telephony Conference

December 2005 [http://www.socialtext.net/iiw2005/index.cgi?informational_morning_for_developers Pre-Syndicate Informational Morning for Developers]
/span>] commons linking together efforts and supporting innovation in user-centric digital identity [http://t.co/rRM74eb Visit the website]

=== Books of Proceedings ===

[[ALL Book of Proceedings PDFs]]

[[Subject Specific Note Collections]]

=== Previous Attendees Lists ===

* IIW 18: http://www.eventbrite.com/event/10266396067/efbnen
* IIW 17: http://iiw17.eventbrite.com/
* IIW 16: http://iiw16.eventbrite.com/
* IIW 15: http://www.eventbrite.com/event/3926801168/efbnen
* IIW 14: http://www.eventbrite.com/event/2785843533/efbnen
* IIW 13: http://www.eventbrite.com/e/internet-identity-workshop-xiii-13-2011b-tickets-1923616589
* IIW 12: https://www.eventbrite.com/e/internet-identity-workshop-xii-12-2011a-tickets-1189831819
* IIW 11: http://www.eventbrite.com/event/785398147/efbnen
* IIW 10: http://www.eventbrite.com/e/internet-identity-workshop-10-2010a-tickets-499632414
* IIW 09: http://www.eventbrite.com/e/internet-identity-workshop-9-2009b-tickets-394204075
* IIW 08: http://www.eventbrite.com/e/internet-identity-workshop-8-2009a-tickets-288845946

IoT Modeling with Picos: “Lessons From Fuse”

2014-10-31T11:14:42Z

WikiSysop:

'''Session Topic:''' loT modeling with PICOs

Wednesday 5F

'''Convener:''' Phil

'''Notes-taker:''' Phil

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

Link to blog discussing topic:

''(Link coming soon)'' http://www.windley.com/archives/2014/10/fuse_with_two_owners.shtml

FIDO U2F Security Key – Emerging Standard Respecting Privacy

2014-10-31T11:12:39Z

WikiSysop:

'''Session Topic:''' FIDO U2F Security Key – Emerging Standard Respecting Privacy

Tuesday 3B

'''Convener:''' Stina

'''Notes-taker:''' John Haggard

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

Link to presentation:
''(Link coming soon)'' http://www.dropbox.com/s/fwwglpx8ralxgvs/FIDO%20U2F%20Security%20Key%20by%20Yubico%20%28IIW%29.ppt?dl=0

Main Page

2014-06-17T13:54:44Z

WikiSysop: Reverted edits by Albertheinz784 (talk) to last revision by Ebgross

<Big> Welcome to the Internet Identity Workshop (IIW) Wiki </big>

[http://www.internetidentityworkshop.com WE HAVE A WEBSITE/BLOG TOO!]

* To get updates regarding IIW [http://lists.idcommons.net/lists/subscribe/iiwinfo subscribe here].

* To join the identity commons community list and dialoguing about user-centric and other identity initiatives [http://lists.idcommons.net/lists/subscribe/community you can do so here].

* To learn more about identity commons linking together efforts and supporting innovation in user-centric digital identity [http://www.idcommons.net/ visit the website]

=== Next Internet Identity Workshops ===
* '''IIW 19 is October 28-30, 2014'''
**[[Note Form]]

=== Previous Internet Identity Workshops & Satellite Events ===
* '''IIW 18 May 6-8, 2014'''
**[[IIW 18 Proposed Topics]]
**[[IIW 18 Notes]]

* '''IIW 17 October 22-24, 2013'''
** [[IIW 17 Proposed Topics]]
** [[IIW 17 Notes]]
** [http://iiw.idcommons.net/File:IIW17_BookofProceedings_2103B.pdf IIW17 Book of Proceedings]

* '''IIW #16 May 7-9 2013
** [[IIW 16 Proposed Topics]]
** [[IIW 16 Notes]]
** [http://iiw.idcommons.net/images/1/13/IIW16_Book_of_Proceedings.PDF IIW 16 Book of Proceedings]

* '''IIW #15 October 23-25 2012'''
** [[IIW 15 Proposed Topics]]
** [[IIW 15 Notes]]
** [http://iiw.idcommons.net/File:IIW15_Book_of_Proceedings.pdf IIW 15 Book of Proceedings]

* '''IIW #14 May 1-3 2012'''
**[[IIW 14 Proposed Topics]]
**[[IIW 14 Notes]]
**[http://iiw.idcommons.net/images/5/51/IIW14_BOP_PDF.pdf IIW 14 Book of Proceedings]

* IIW-Satellite Sydney
** [[IIW Satellite Sydney Notes]]

* IIW-Satelite DC
** [http://iiwsatellitedc2012.eventbrite.com/ Attendee List]
** [[IIW Satelite DC Proposed Topics]]
** [[IIW Satellite DC Notes]]

* IIW #13 October 18-20 2011
** [[iiw13 Proposed Topics]]
** [[IIW 13 Notes]]
** [["NSTIC Day" Proposed Agenda]]
** [[http://iiw.idcommons.net/File:IIW13_BOP_PDF.pdf IIW 13 Book of Proceedings]]

* IIW #12 May 3-5, 2011 at the [http://itshumour.blogspot.com/2009/09/top-10-hilarious-quotes.html hilarious quotes] Computer HIstory Museum in Mountain View California [http://www.casinoluckywin.com/en/games/slot_games/ best online slots]
** [[iiw12 Proposed Topics]]
** [[IIW 12 Notes]]

* Identity Collaboration Day, Feb 14, 2011 - Day before RSA, for discussion of user-centric, enterprise [http://www.hockeychamp2014.com/world-hockey-championships.html IIHF Hockey] and government identity initiatives.
** [http://www.idcolab.eventbrite.com ID Collaboration Day Registration/Description]
** [[IDCollab Proposed Topics]]
** [[IDCollab Day Notes]]

* IIW #11 Fall 2010 [[iiw11]] Nov 2-4, Tuesday-Thursday at the Computer HIstory Museum in Mountain View California
** [[Notes IIW11]]
** [http://www.internetidentityworkshop.com/what-is-iiw/ Responses to IIW is...] [http://bit.ly/dt3ruz Values of IIW]

* [[iiw-europe-1|IIW Europe]] in London Monday October 11 (before RSA Europe) at the University of London [http://www.imcredo.com/services/ppc/ Adwords Management]
** [[iiw-europe-1-Notes]]
** [[iiw-europe-1-Reflection]] As a Result of Today....

* [[iiw-east-1|IIW East Coast]] in DC September 9-10 Thursday, Friday at the Josephine Butler Parks Center (following the Gov 2.0 Summit) the [http://www.thefunnyquotessayings.com/cool-hilarious-funny-quotes-sayings/ funny quotes sayings] theme will be ''Open Identity for Open Government''
** [[Notes_IIW-East]]
** [[As a result of day 1 at IIW-East]]

* #10: Spring 2010 [[iiw10]] May 17-19 at the Computer History Museum.
** [[Notes IIW10]]

* #9: Fall 2009 [[iiw9]] TUESDAY November 3 to THURSDAY November 5.
** [[Notes_iiw9]]

* #8: Spring 2009 [[iiw8]] - '''May 18-20, 2009'''
** [[Notes_iiw8]]

* #7: Fall [[iiw2008b]] (2008B)- '''Nov 10-12''' - Computer History Museum, Mountain View, CA
** [[Notes_08b]]

* 6: Spring [[iiw2008a]] (2008A)- '''May 12-14, 2008''' - Computer History Museum, Mountain View, CA
** [[Notes_2008a]]

* [http://iiw.idcommons.net/index.php/Iiw2007b 5: December 3-5, 2007 - Computer History Museum, Mountain View, CA]

* [http://iiw.windley.com/wiki/Workshop_2007 4: May 2007 - Computer History Museum, Mountain View, CA]

* [http://iiw.windley.com/wiki/Workshop2006b 3: December 2006 - Computer History Museum, Mountain View, CA]

* [http://iiw.windley.com/wiki/Workshop2006 2: May 2006 - - Computer History Museum, Mountain View, CA]

* [http://www.socialtext.net/iiw2005/index.cgi?internet_identity_workshop_2005 1: October 2005 - Berkeley, CA]

=== Previous Identity Open Spaces ===

Identity Open Space events are co-produced by the IIW team (Phil, Kaliya, Doc) in collaboration with other organizations and events. To date we have worked with Digital Identity World and the Liberty Alliance. [http://www.grabcasinobonus.com/casino-bonuses/ Mobile Casino Bonus] We are open to working with a variety organizations - if you are interested please don't hesitate to contact us. [http://ios.windley.com/wiki/IOSSF September 2007 at Digital Identity World]

[http://ios.windley.com/wiki/IOSBrussels May 2007 following a Liberty Alliance Meeting in Brussels, Belgium]

[http://ios.windley.com/wiki/IOSSantaClara September 2006 at Digital Identity World]

=== Previous Identity Birds of a Feather Meetings ===

June 2006 [http://www.identitygang.org/ Identity Gang Birds of a Feather Session] at Burton Group Conference, San Francisco

January 2006 [http://www.socialtext.net/iiw2005/index.cgi?identity_speed_geeking_o_reilly_emerging_telephony_conference Identity Speed Geeking Session] at O'Reilly's Emerging Telephony Conference

December 2005 [http://www.socialtext.net/iiw2005/index.cgi?informational_morning_for_developers Pre-Syndicate Informational Morning for Developers]
/span>] commons linking together efforts and supporting innovation in user-centric digital identity [http://t.co/rRM74eb Visit the website]

=== Books of Proceedings ===

[[ALL Book of Proceedings PDFs]]

[[Subject Specific Note Collections]]

=== Previous Attendees Lists ===

* IIW 18: http://www.eventbrite.com/event/10266396067/efbnen
* IIW 17: http://iiw17.eventbrite.com/
* IIW 16: http://iiw16.eventbrite.com/
* IIW 15: http://www.eventbrite.com/event/3926801168/efbnen
* IIW 14: http://www.eventbrite.com/event/2785843533/efbnen
* IIW 13: http://www.eventbrite.com/e/internet-identity-workshop-xiii-13-2011b-tickets-1923616589
* IIW 12: https://www.eventbrite.com/e/internet-identity-workshop-xii-12-2011a-tickets-1189831819
* IIW 11: http://www.eventbrite.com/event/785398147/efbnen
* IIW 10: http://www.eventbrite.com/e/internet-identity-workshop-10-2010a-tickets-499632414
* IIW 09: http://www.eventbrite.com/e/internet-identity-workshop-9-2009b-tickets-394204075
* IIW 08: http://www.eventbrite.com/e/internet-identity-workshop-8-2009a-tickets-288845946

OIX

2012-11-08T11:58:16Z

WikiSysop:

'''Session:''' Tuesday Session 3 Space E

'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW 10 ] May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes ]

Convener: Don Thibeau, Drummond Reed

Notes-taker(s): Christie Grabyan

;A) Tags for the session - technology discussed/ideas considered:
Catch up on what has happened in the last 6 months, plus review of what OIX is today.
;B) Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Defined: [http://openidentityexchange.org/ OIX] is a community-developed solution to the problem of how open identity credential ([http://openid.net/ Open ID], [http://informationcard.net Info Cards]) can be trusted online.
Up-to-date:
6 months ago the discussion was primarily around terminology and getting everyone on the same page.

Recent developments include:
(March 2010)
* OIX launched at RSA
* Approved as US ICAM TFP
* First 3 ICAM IdPs certified
* Open Identity Trust Framework Model paper published
(May 2010)
* Working groups commence
* Expanded membership doc approved

==Review of the OITFP Model==
Under the OITF Model, the Trust Framework Provider (TFP) communicates with the Identity Service Provider (IdP), the Relying Party (RP) and the Assessor. The IdPs and the RPs interact directly with the Users. The IdP provide levels of assurance to users and assessors, and the RPs provide levels of protection to users and assessors.

The feedback from the industry and the priority was to make OIX: simple, lightweight and extensible. Deliberately designed for global scalability, with enough room for policymakers and other trust framework providers to enter.
Data protection notions are already well-defined, therefore it is anticipated that there will be objectively testable levels of protection that could be defined, tested, and assessed.

For example, NIST levels can be leveraged as a framework.

The role of ICAM has bridged both technical and policy requirements. ICAM is Identity Credential Access Management: a committee of committees in the US government with a co-chair from the DoD (Dept of Defense).

In the UK, there are also notions of registration authority, credential providers, and identity providers that all fit into OIX’s sense of “Identity Service Provider”

Question was posed as to who accredits the assessor? Accreditation could be provided by the TFP. Pr, a role called a Special Assessor could be designated by the TFP (maybe it will become a government agency, or some of the Big5 firms, etc).

In the health sector, there is a problem with the identity side of the equation, but there are also problems with the RP side. The challenge is does that RP qualify to offer services in the health sector (or other sector)?

Question around Liability: Does the TFP provide direct indemnification? Are they are rating agency or a guarantor?

Answer: The liability issue is being explored right now, including where are the balance of duties, what kind of contractual elements need to be put in place, if legislation is required, etc. There is a desire to have an industry-lead discussion around liability, rather than wait for the government to tackle it. The intention of lightweight assessor responsibilities in the first phase is a placeholder to allow for working groups and other trust frameworks to chime in and provide more context so that decisions can be made to further define the responsibility of assessors.

Questions: Who accredits TFPs? Answer: The policymakers themselves.
TFPs will multiply. It is not designed to produce a TFP monopoly.

Other trust frameworks are coming…..
* Line Information Database (LIDB) - To safeguard access to telco subscriber data
* PBS Public Media – To connect public TV stations, users, and sites
* XAuth – To simplify movement between social sites
* PDX (Personal Data Exchange) – To support individual data on their terms

Question: What is the sustainable model for these trust providers, particularly for OIX which is solely in the trust business, and doesn’t have other revenue streams to rely on?

Answer: With OIX, the business model is based on membership fees (by assessors, RPs, etc). Longer term, the goal is to support the cost of maintaining the listing cost.

The listing service (meta-federation) needs to be designed before further decisions can be made about how to operate and maintain it.

Credit card operating rules model is already established in this space.

There will be a session on Wednesday to discuss the PCI trust model and terminology.

There are OIX TF Working Groups to join to further the discussion.

OIX

2012-11-08T11:57:47Z

WikiSysop:

----
'''Session:''' Tuesday Session 3 Space E

'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW 10 ] May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes ]

Convener: Don Thibeau, Drummond Reed

Notes-taker(s): Christie Grabyan

;A) Tags for the session - technology discussed/ideas considered:
Catch up on what has happened in the last 6 months, plus review of what OIX is today.
;B) Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Defined: [http://openidentityexchange.org/ OIX] is a community-developed solution to the problem of how open identity credential ([http://openid.net/ Open ID], [http://informationcard.net Info Cards]) can be trusted online.
Up-to-date:
6 months ago the discussion was primarily around terminology and getting everyone on the same page.

Recent developments include:
(March 2010)
* OIX launched at RSA
* Approved as US ICAM TFP
* First 3 ICAM IdPs certified
* Open Identity Trust Framework Model paper published
(May 2010)
* Working groups commence
* Expanded membership doc approved

==Review of the OITFP Model==
Under the OITF Model, the Trust Framework Provider (TFP) communicates with the Identity Service Provider (IdP), the Relying Party (RP) and the Assessor. The IdPs and the RPs interact directly with the Users. The IdP provide levels of assurance to users and assessors, and the RPs provide levels of protection to users and assessors.

The feedback from the industry and the priority was to make OIX: simple, lightweight and extensible. Deliberately designed for global scalability, with enough room for policymakers and other trust framework providers to enter.
Data protection notions are already well-defined, therefore it is anticipated that there will be objectively testable levels of protection that could be defined, tested, and assessed.

For example, NIST levels can be leveraged as a framework.

The role of ICAM has bridged both technical and policy requirements. ICAM is Identity Credential Access Management: a committee of committees in the US government with a co-chair from the DoD (Dept of Defense).

In the UK, there are also notions of registration authority, credential providers, and identity providers that all fit into OIX’s sense of “Identity Service Provider”

Question was posed as to who accredits the assessor? Accreditation could be provided by the TFP. Pr, a role called a Special Assessor could be designated by the TFP (maybe it will become a government agency, or some of the Big5 firms, etc).

In the health sector, there is a problem with the identity side of the equation, but there are also problems with the RP side. The challenge is does that RP qualify to offer services in the health sector (or other sector)?

Question around Liability: Does the TFP provide direct indemnification? Are they are rating agency or a guarantor?

Answer: The liability issue is being explored right now, including where are the balance of duties, what kind of contractual elements need to be put in place, if legislation is required, etc. There is a desire to have an industry-lead discussion around liability, rather than wait for the government to tackle it. The intention of lightweight assessor responsibilities in the first phase is a placeholder to allow for working groups and other trust frameworks to chime in and provide more context so that decisions can be made to further define the responsibility of assessors.

Questions: Who accredits TFPs? Answer: The policymakers themselves.
TFPs will multiply. It is not designed to produce a TFP monopoly.

Other trust frameworks are coming…..
* Line Information Database (LIDB) - To safeguard access to telco subscriber data
* PBS Public Media – To connect public TV stations, users, and sites
* XAuth – To simplify movement between social sites
* PDX (Personal Data Exchange) – To support individual data on their terms

Question: What is the sustainable model for these trust providers, particularly for OIX which is solely in the trust business, and doesn’t have other revenue streams to rely on?

Answer: With OIX, the business model is based on membership fees (by assessors, RPs, etc). Longer term, the goal is to support the cost of maintaining the listing cost.

The listing service (meta-federation) needs to be designed before further decisions can be made about how to operate and maintain it.

Credit card operating rules model is already established in this space.

There will be a session on Wednesday to discuss the PCI trust model and terminology.

There are OIX TF Working Groups to join to further the discussion.

Iiw-east-1

2012-11-08T10:45:43Z

WikiSysop:

[http://www.internetidentityworkshop.com We also have a Website and blog with current information about our events].

The first IIW to be held outside the Bay Area will be held in DC, September 9-10, Thursday and Friday (following the Gov 2.0 Summit)

IIW East Coast #1 will have the theme ''Open Identity for Open Government'

Location [http://www.washingtonparks.net/parkscenter.html Josephine Parks Butler Center]

** [[IIW-East-1-Notes]]
** [[As a result of day 1 at IIW-East]]
** [http://iiweast.eventbrite.com See attendee list at the bottom of this page]
** [http://twitter.com/idworkshop/iiw-east1 Twitter List for the event]
** [[Proposed Topics IIW-East-1]]
** [http://www.internetidentityworkshop.com/iiw-east-in-dc-open-identity-for-open-government/ See the Invitation]

Trust Frameworks Analogue to Digital Converters

2012-11-08T09:49:09Z

WikiSysop:

'''Issue/Topic:''' Trust Frameworks as Analog o Digital Converters

'''Session:''' Tuesday 1B

'''Conference:''' [http://iiw.idcommons.net/Iiw11 IIW-11] November 2-4, Mountain View, [http://iiw.idcommons.net/Notes_IIW11 Complete Notes Page]

'''Convener:''' Scott David

'''Notes-taker(s):''' Jamie Clark

'''Tags:'''

trust_framework, taxonomy, contracts, risk_allocation, UI

'''Discussion notes:'''

[[File:Nov_2_Rethinking_Personal_Data_Workshop.pdf ]]

Facilitating Personal Data Transactions in a Secured Manner on a
Global Scale": part of presentation for WEF (Davos) prep session on
"Rethinking Personal data" workshop, New York, September 2010; should
be posted shortly to OIX website

What's the international law of identity?

There isn't any.

Can we do things with law and/or rules and/or tech to weave together the
disparate systems that interact?

What should identity systems do? Meet "system participant" (user) needs. Such
as:
* data subjects need identity integrity
* replying parties need assurance
* identity providers need risk reduction
These high-level 'needs' share some basic lower-level functional requirements
like, security, reliability, UI, etc.

What can tech and law do about this?
* technology tools guide data movement & protect data at rest
* legal rules create duties to incent behavior

-- By far most of the data breaches I've seen (S. David) were human error, not
tech failure. So the human rules and incentives matter.

A "Trust Framework" is a possible documentation style ("term sheet"?) for the
agreed risk and reliance arrangements between system participants.

There is some "low hanging fruit" of law and practice guiding these duties:
* In the US: NSTIC, Levels of Assurance. In some states, data breach laws.
* Privacy laws like HIPAA, Gramm-Leach, FICA, etc.
* Fair Info Practice Principles (originally US DHEW 1973) - levels of
control

ABA drafting a report on Federated Identity which addresses a taxonomy of
issues and actors; OIX doing a "risks wiki"; some out for public review now;
posted work product expected early 2011(?)

One difficulty is operationalizing assurance which is mostly processed by
end-users as emotional states like "trust", "reliability." Quantification
needed, to clear the semantic fog here.

The idea here is to address some recurring liability issues, but not all.
80/20 approach, not boiling the ocean. May be industry groups and self-
regulatory efforts that give rise to the best evolving solutions.

First step is a candidate common analytical framework, to get to "apples-to-
apples" on some of the risks, practices and concepts

Inspirational vision: UI simplification - risks and control issues displayed
simply like red-light-yellow-light-green-light displays.

Audience: Frameworks generally get developed in a context of siloes -
non-interoperable specialized cases. Is there a "metalanguage" for crosswalks
among the privacy practices of those siloed players? Or 15% of them, anyway,
for scalability's sake.

''there is a PPT deck associated with this session: "nov 2 Rethinking Personal Data Workshop.ppt"''

Schema Mapping Using Personal Data Madel

2012-11-08T09:05:53Z

WikiSysop: Undo revision 5361 by Bailey Helton (talk)

See this blog post for details: [http://www.incontextblog.com/?p=463 Incontextblog: Schema Mapping session at IIW]

'''Convener''': Paul Trevithick

'''Notes-taker''': Joe Andrieu

'''Tags''':
Attributes, claims, schema mapping, semantics, persona

'''Discussion notes:'''

Used to think that we could figure out a common schema. But realized that is too hard. Human nature is such that we want the power to mint the names and titles of the terms we use in /our/ systems.

So what Paul has been working on an open source schema for information about human beings: first name, etc... If you make a rich complex schema, it ends up being complex. It's easy to do the dumb things and keep it simple. Hard to do anything that captures the richness of reality without having significant complexity. This schema mixes and matches from tons of places and is intended to capture EVERYTHING, even if no one uses it directly. But you can build schema mapping in & out of this schema for whatever the input and output need to be.

When working on a schema, it is typically done with a specific purpose in mind, which leads to many different schema. So, let's embrace that and have a vehicle for mapping in and out of each of these.

Question: Doesn't that bring up issues about language discovery?
RP wants a claim "X". It asks the IdP. "X" must be golabally unique. If the IdP doesn't have "X", it can try to find a transformation path to product "X" from the data it does have available.

Note that a given transformation could take multiple steps from multiple different transformation rules. And if we have a big, rich central transformation ruleset (Y), then for most transformations, all you need is to be able to map in & map out.
Also, the more granular the base Y, the easier it is to scope in and out... there are more possible transformations the more granular data.

It's faster for me to figure out how to do it on my own rather than to go learn some other ontology. This fuels the cacphony.

(What are the rules? Inference rules?)

Persona?

Not clear what that means? Is it the role a person is in? Perhaps thats just a claim?

Uses some RDF and leverages interesting SPARQL stuff, but in the end, it doesn't need complicated SemWeb tech.

SAML and OAuth

2012-11-08T09:04:59Z

WikiSysop: Undo revision 5260 by IntelpNeelok1 (talk)

'''SAML & OAuth V2'''
Nov 19/09 - IIW
Paul Madsen

'''Goals'''
* Explore (useful) combinations of SAML & Oauth
* Builds on 2008 proposal from Ping ID for combining SAML SSO & Oauth authz sequence
* Learn from OpenD Oauth Hybrid extension

'''SAML & OAuth'''
* OAuth does not stipulate how the user authenticates to either the SP or Consumer
* SAML SSO can provide the authentication
* If so, question is whether/how the SAML messages by which SSO happens can facilitate the fundamental Oauth sequence of
# Obtaining User authorization (consent) of a request token
# Getting the authorized request token from the SP to Consumer

''OpenID community calls this scenario 'hybrid', SAML/Liberty a
'boostrap'''

'''Oauth Request params'''
* The OpenID Oauth hybrid model does away with the initial server-to-server call by which the Oauth Consumer gets an unauthorized request token
* Consequently, instead of carrying an unauthorized request token and asking for its approval, the OpenID request carries an implicit 'return an approved request token' request
* Request includes Consumer_Key, maybe not Consumer_Secret, callback_url....

'''SAML extensibility'''
• SAML provides flexible extensibility model by which protcol messages (e.g the <AuthnRequest> and <Response>) can be extended with XML elements from other namespaces
• SAML defines some core attributes but new ones can be spun up as necessary
• Depending on SAML/OAuth roles played by actors, we'll need one or both of extension points

'''#1 SAML Idp == Oauth SP'''
* In the simplest case, the SAML IdP == Oauth SP & SAML SP == Oauth Consumer
* As in the OpenID Oauth Hybrid extension
* Challenge is to get the User & Oauth request params from Oauth Con to the Oauth SP, and get the authz request token back
** Use SAML AuthnRequest to carry the Oauth request params from Oauth Con to Oauth SP
** Use SAML <Response> and <Attribute> within to carry the authz request token back

'''#1 Extension Needs'''
* Define Oauth extension to SAML AuthnRequest to carry Oauth params from SAML SP(OAuth Con) to SAML IdP(OAuth SP)
* Define SAML Attribute to carry the approved request token from SAML IDP(OAuth SP) to SAML SP(OAuth Con)

2) SAML Idp == Oauth Con
* And SAML SP == Oauth SP
* Implies separation of roles between authentication and attribute storage/sharing
* User authenticates at SAML IdP, but must give consent/authorizations at Oauth SP
* Challenge is get Oauth request params from SAML IdP
to SAML SP/OAuth SP in order to obtain Oauth consent (and eventually get an authorized request token returned )
** Use unsolicited SAML <Response> and <Attribute> within to carry Oauth request params
** Rely on Oauth msg to get the authz request token from Oauth SP to OAuth Consumer

'''#2 Extension Needs'''
* Define SAML Attribute to carry Oauth request params from SAML IDP (Oauth Con) to SAML SP (Oauth SP)

'''3) SAML SP1==OAuth SP& SAML SP2==OAuth Con'''
* Most general case, SAML IdP not involved in attribute sharing
* User authenticates at SAML IdP, SSOs to two distinct SAML SPs (an Oauth SP & an Oauth Consumer respectively)
* Challenge is to get the User & Oauth request params from the first SAML SP to the second in order to obtain consent, and the authorized request token back
** Use SAML 3rd party requestor extension to get Oauth request parsms from Oauth Consumer to Oauth SP
** Rely on Oauth msg to get the authz request token from Oauth SP to OAuth Consumer

#3 Extension Needs
* Leverage the SAML 3rd party Requestor extension to indicate IDP should send SAML response to Oauth SP2
* Define Oauth extension to SAML AuthnRequest to carry Oauth request params from SAML SP1 to SAML IdP
* Define SAML Attribute to carry Oauth request params in a Response from SAML
IDP to SAML SP2

Poor Man Verified ID

2012-11-08T08:47:29Z

WikiSysop: Undo revision 5364 by James Carlson (talk)

'''Issue/Topic:''' Poor Man’s Identity Verification

'''Session:''' Wednesday 2G

'''Convener:''' Jon Webb

'''Conference:''' [http://iiw.idcommons.net/Iiw11 IIW-11] November 2-4, Mountain View, [http://iiw.idcommons.net/Notes_IIW11 Complete Notes Page]

'''Notes-taker(s):''' Jon Webb, Dan Miller

'''Tags:'''

Verified Identity, anonymity, delegated authority

'''Discussion notes:'''

Brainstorm format:

What do people want to verify?
* Confirm address
* Employment verification
* Job role verification
* Jon Webb Sony Playstation wants verification that the user is who they claim to be and that it hasn't changed since the last time seen (Playstation has 50mm+ users)

How to prevent account sharing that degrades quality of service for the network and other users?

Q: did people consider delegated authorities?

A: People have less need to share account information since they can delegate use appropriately

e.g. edit timesheets on another’s behalf, manage parental consent for minors, allow trusted users to conduct banking activities

Noted that systems to implement delegated authority have really only been deployed in the enterprise space, not much in the consumer space. UX in consumer space is a concern.

Pat From Equifax. Studying parental consent issue. Verifying 1.5mm users per day. Community filtering of sex offenders is common.

Allan from HP presented an interesting approach at last year’s IIW that had to do with provisioning with an unguessable URL

Need to keep it low friction.

You could put additional challenge response cycle

Pat: You need very little info to verify ID. But it depends on the problem you're trying to solve, what kind of data and what do you need to verify, it comes down to what's the business case

Verification generally happens out of band

Password maps are hard to transfer between users. They are a personalized image where elements of the image are the password

Multifactor to avoid

How to assert ID without promoting a way for them to share the id

Discussed credit cards as an imperfect form of identity

VERIFIED IDENTITY CLAIMS – Selectors (W3A)

2012-11-07T15:27:17Z

WikiSysop: Undo revision 4978 by Nnenne (talk)

'''Issue/Topic:''' VERIFIED IDENTITY CLAIMS – Selectors (W3A)

'''Session:''' Wednesday 3A

'''Conference:''' [http://iiw.idcommons.net/Iiw11 IIW-11] November 2-4, Mountain View, [http://iiw.idcommons.net/Notes_IIW11 Complete Notes Page]

'''Convener:''' Craig Wittenberg (Microsoft)

'''Notes-taker(s):''' Ariel Gordon (Microsoft)

'''Tags:'''
Identity Selectors; Verified Claims; Identity Attributes; Privacy; Privacy Enhancing Technology; User-control.

'''Participants:'''

*Craig Wittenberg Microsoft
*Ariel Gordon Microsoft
*Pat Mangiacotti Equifax
*Mary Ruddy Meristic
*Brian Kissel Janrain
*Greg Hauw Ohanae
*Brad Hill ISEC Partners
*Dale Olds Novell
*Pamela Dingle Ping Identity
*Van Miranda Socialcast
*Diana Smeltas Google
*Naveen Agarwal Yahoo
*Eric Sachs Google
*Paul Trevithick Azigo
*Dave Hebert Microsoft
*George Fletcher AOL
*Lloyd Burch Novell
*Greg Turner Sierra Systems
*Michael Fischer Stanford
*Jeff Hodges PayPal
*Eve Maler PayPal

'''Discussion notes:'''

Verified Identity Claims – How to implement identity/claims selectors

Scoping to the scenarios where privacy requirements mandate a “separation” between claim provider and relying party, e.g. non traceability.
Framing from the perspective of verified claims—adds some requirements. However, the model can be used for any type of claims (verified or self-asserted).

''a word diagram goes here''

Problems: where should the Selector run?
- If the selector runs on the client, we need to update/manage its lifecycle, enable portability/roaming, etc.
- If the selector runs in the cloud, then one of the major question is who has the keys? (with U-prove tokens, the agent is storing the keys). In this case, the cloud service has the keys and could potentially impersonate the user.

There are many potential UX problems…

We should separate the Login problem from the Exchange of verified claims problem.
Does the user need to authenticate to the cloud-based selector?

Potentially, the user may need to authenticate N+1 times (once to the selector and N times for the N claim sources)…

Paul Trevithick (Azigo): Having the Selector remember my passwords to IdPs/Claims provider is a bad design.
Long-live tokens can address part of the problem because the selector could retrieve a bunch of tokens from the Claims provider to spend later—and not have to save the credentials.

George Fletcher (AOL): the Cloud Selector will now more about what the user is doing than the IdPs and the RPs.
That’s true— but if it’s operated as a different party from the IdP and is under the user’s control, this is already better than the current IdP-centric model.
However, it is true that the cloud selector becomes the center of this relationship knowledge, and this is clearly one of the downside of implementing the selector as a cloud service. Implementing as a device local service would mitigate that. There might be other, “hybrid” options with limited functions that run on the client.

Pamela Dingle (Ping): think of this as a User-centric Attribute Broker (instead of a selector/agent).
The authentication methods are left to the service providers (outsourced).

Elements that will influence the design process:
- Multiple tokens
- Login to IdP vs. long live tokens; extra auth?
- User preferences
- Nascar
- What drives discovery? Should there be a way to provision the relationship with IdPs/claims providers to the selector?

Eve Maler (PayPal): Standardizing claims type (building a dictionary?) and referencing valuable claim sources?

Goal: valuable claims need to be available for everyone. Possibly offered my multiple providers.

Paul: This may be the reinvention of user-centric identity and links naturally to the Personal Data Store discussion.

[[File:IIW11_WED_3A_1.JPG|700px]]

[[File:IIW11_WED_3A_2.JPG|700px]]

User Managed Access: User Interface

2012-11-07T15:18:07Z

WikiSysop: Undo revision 4376 by OffRa.mp (talk)

'''Session topic:''' User-Managed Access Authorization Manager UX Study (W3E)

'''Convener:''' Maciej Wolniak, Lukasz Moren (Newcastle University)

'''Notes-taker(s):''' Maciej Machulak

'''Tags for the session - technology discussed/ideas considered:'''

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

Maciej presented the UX study on the UMA Authorization Manager. First, introduction on UMA, then description of the research study, the description of the 1st version of AM, then research results, then the new AM and conclusions.

  Research study:

 Learnability, efficiency, memorability, errors recovery, satisfaction

 - this are the usability factors that have been assessed. 
* 34 participants 
* men and women, age 19-50 
* questionnaire-based: interviews and online form 
* sample task 
* participants’ feedback

    Study results: 

users found the manager complex due to many steps in the process
* confusing colour scheme
* respondents reported the layout to be comprehensible 
* they stated it could have been better 
* major flaw, confusing headlines

* illogical layout - elements do not correspond with the steps of the task
* counter intuitive – drag boxes
* accordion module 
* vague form fields 
* lack of colours 
* more help requested

   Based on the initial research study, the following user-required improvements have been defined:
* more intuitive
* more logical
* more visual
* more colours 
* more precise form fields  

Then, the new Authorization Manager (SMART AM V2.0) is shown - the previously defined sample task is shown using the new UI - there’s a small difference in comparison to the earlier task - resources are not registered at the AM but are registered from the Host application (e.g. user clicks the Share button).

  Question: Was that the conscious choice to have all the information when defining a policy on a single screen?

 Answer: Yes, this was to provide a user with a consistent and easy to use UI. At this point of time, there’s only a minimum amount of information that can be managed at the AM. If we wanted to introduce additional features (e.g. calendar to specify that permissions are valid for a certain period of time) then we would probably for a wizard-like screen.  

Comment: There's a necessity to evaluate the understanding of the Authorization Manager, not only the usability. The usability might be good but the understanding might be low (because UMA is quite a new model and may be confusing for the users).

  Lessons learnt from the UX study: 
* keep the UI simple 
* emphasise key features
* show only necessary options
* indicate current stage in the cycle

  When the user clicks on Share being at the Host then he knows the context of the actions he performs (i.e. in the previous SMART AM the user would register resources from the AM side and not from the Host side).  

Newcastle University team plans to continue the work on the Authorization Manager: 
* conducting another UX research 
* include at least the same number of participants (preferably more) 
* perform a new user evaluation study based on the new user interface
* apply the same questionnaire – try thinking aloud method or voice recording

  There's a necessity for heuristic evaluation - small number of usability experts assesing the UI (3-4 people).  

You can check out http://www.smartam.net and comment futher.  It would be great to provide more integration points between the host and the AM..

Demo with Freedom Box (you can participate!)

2012-11-07T13:24:49Z

WikiSysop:

'''Session Topic:''' FreedomBox Demo (T3C)

'''Convener:''' Markus Sabadello

'''Notes-taker(s):''' Markus Sabadello

In this demo, 5 plug computers (Guruplugs by GlobalScale Technologies) were handed out to volunteer participants and connected to power outlets.

Upon being plugged in, these small personal servers booted their Debian operating system and custom demo software.

Each volunteer of the demo was able to control one of the boxes via a web interface.

The first step was to connect one's box to the other boxes.

The second step was to sign in to the network with an identifier, in order for boxes to be able to find each other.

After being connected and identified, the demo allowed participants to do the following:
* 1. Enter personal data which is stored in an XDI-based Personal Data Store on the box (first name, last name, email, etc.)
* 2. Establish a relationship with other participants, which allowed access to the personal data on their boxes via XDI Messaging.
* 3. Sending text messages from one box to another.
* 4. Sending an "intent" to all boxes on the network, indicating what one would be willing to buy at a given price.
* 5. Viewing "intents" received from the network.

There was a lot of good discussion about the potential of such a personal server for the Personal Data Ecosystem and Vendor Relationship Management.

The general idea behind the FreedomBox is to enable data sharing, communication and social networking that can not be monitored or censored.

This demo was neither created nor endorsed by the FreedomBox Foundation, but was simply meant to demonstrate what its idea is about.

The actual software used during the demo was developed by Project Danube.

Biz Case for Data Portability

2012-11-07T11:56:34Z

WikiSysop: Undo revision 3230 by Igiwydijok (talk)

Convener: Elias Bizannes

'''Tags:'''

Business case, modeling, portability, economics, adoption, maximizing value

'''Discussion notes:'''

Dataportability Business Case
Information Value Chain

P (Data creation -> Information generation -> Knowledge Application)

S [storage] [processing] [distribution & socialisation]

Theory: Specialization leads to comparative advantage

If you get different people focusing on one key part of the chain each, then everyone can get better value, thanks to specialization.

Counter: However, diversification is more profitable than specialization… or at least it appears that way. Because of customer acquisition costs, many companies work to maximize how much they can monetize from each customer by offering more and more services and functionality.

Perhaps improved data quality and the resultant reduced costs is significant. "50% of a Business's cost infrastructure exists to compensate for not knowing what the Consumer already knows…"

John McKean, Author "Information Masters - Secrets of the Customer Race". www.informationmasters.com .

So, is the business case 100% cost savings?

Not necessarily. What about e-commerce that can reduce the % of abandoned shopping carts?

Perhaps the measure is engagement?

Counter: The primary theory doesn't necessarily actually encourage or suggest or explain the business case for data portability. It supports specialization, but that could lead simply to kieretsu-based dependencies between members of the chain. In order to make a case for portability, you'd have to make the case for interchangeability between elements in the same layer in the value chain.

Key obstacles to adopting this kind of model?

1. does it make sense
2. cultural? NIH & thinking in specialist models

Recommendation: the Big Switch

Trust Framework System Rules - Business, Legal, Technical

2012-06-13T13:40:30Z

WikiSysop: Undo revision 5597 by Jmarry89 (talk)

'''Session Topic: Trust Framework System Rules''' (TH3F)

'''Convener:''' Dazza Greenwood (@dazzagreenwood)

'''Notes-taker(s):''' Eve Maler (@xmlgrrl) and Jamie Clark (@JamieXML)

'''Tags for the session - technology discussed/ideas considered:'''

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

Resources under discussion are generally available at: http://civics.com/

What's the definition of a trust framework? Does it have boundary conditions? Is it a "club with rules"? The rules seem to have business, legal, and technical aspects. Could the boundaries be set dynamically? Perhaps, but it seems odd to include someone in the club without their knowing it.

Accounting for the regulatory aspects of trust frameworks is challenging. Better to just consider all "contractual" elements? Trust framework system rules are multilateral agreements. That set of contractual elements are not literally regulatory. Private parties get together and define a boundary for their "bubble".

Does such an agreement have to be legally enforceable? Are a bunch of tennis partners that expect each other to take turns buying the beer afterwards could be described as being (lightly) bound by a trust framework. But generally, what's at stake has high value in the aggregate, so enforcement -- whether legal or getting kicked out of the club -- is a part of the expectations.

For today's discussion, we're talking about explicit, written, agreements that involve business, legal (ideally enforceable), and technical elements. There are elements of verification, duties, and so on. Precedents: payment systems (e.g. ACH), supply chains (e.g. EDI), credit cards (e.g. VISA), and identity federations (e.g. InCommon)

People tend get lightly bounded when they visit a site through at least click-through ToS agreements or similar. Other ways of entering a trust framework are typically more tightly bounded. An important component of rules is exception rules, or "error trapping".

The Technical super-section of the sample Table of Contents starts with use cases, to capture the scope. The Legal super-section might include legal criteria for participation, so that (e.g.) for a insurance industry framework, shoe sellers wouldn't be eligible. Standardized liability statements aren't really available; they tend to be quite specific to the circumstances.

Dazza will soon publish his recent work on the insurance industry trust framework that he showed today. See other samples at: http://civics.com/idfederation-framework/

Trust frameworks have to emit pheromones that say "come play", so that they'll survive.

How do parties know what trust frameworks they should be joining? Right now, there are a bunch of efforts that aren't really ready to be joined yet. How to translate the credit card model to identity? OIX et al. are creating tools around this, but for right now, you'd probably know about them because they're idiosyncratic to your community. The trust mark aspect of the TOC shows a way that trust frameworks could be branded. This typically involves certification so that you can use the mark. Think of UL listing: http://www.ul.com/global/eng/pages/ In the future, maybe we'll see "OIX Listed" sites.

Cisco connects to 400 providers. It's painful to set each of these up. The use cases include both B2B and SaaS connections.

A lot of the TOC comes from or is inspired by the "PKI days". The supposed openness of those early projects actually added friction because people weren't sure if they were or should be considered within the boundaries. So the more bounded frameworks have worked better since. This is why business use cases are the starting point for filling out the TOC. There's an ROI for each potential member; some may choose not to join, or not to join now. The whole point of the multilateral agreement is scalability; this is a big part of the value.

Dazza is working with Jamie and OASIS to standardize this TOC approach. Operating rules/system rules are a persistent phenomenon. If you don't have rules like this, you basically can't "federate" (= operate under some set of rules).

Historically, forming the framework has been a matter for deep experts only, and it's had trouble scaling because the work product looks like it. :-) The current rules would "gag a yak" :-), and thus don't scale to the consumer market.

Typically it's "RPs" (parties who need to be assured that others' interests will sufficiently align with theirs) who get together and become the policymakers that create the rules. See: http://openidentityexchange.org/sites/default/files/the-open-identity-trust-framework-model-2010-03.pdf

Perhaps what we'll see is some successive approximation over time, a la open source licenses. Interoperability starts to become a well-known best practice.

What about the VRM fourth-party type of discussion? And what about other use cases that don't strictly use the IdP/RP/user triangle? Does the system rules model sale to n parties? Yes; you can define as many roles as you want. A party might be in more than one role, so you may have to consider interlocking duties.

"User-centric" frameworks are new, but Dazza had an opportunity to work on a research project that was related to veterans returning from war and using an Android app that behaviorally predicts PTSD etc. What do you with highly sensitive mobile, personal, and military data? The advice he got was to take the veteran's point of view in doing the system rules. This has a strong personal datastore aspect. Here's an example: http://civics.com/pd-tf-sysrules/

Some other trust frameworks Dazza has known and loved before: http://civics.com/trust-frameworks/

Dazza is starting to share some standard clauses between these projects and XACML and SOA system rules. These are shaping up to look a bit like the UMA Trust Model rules: http://kantarainitiative.org/confluence/display/uma/UMA+Trust+Model

Starting with the assumption that the individual owns their personal data and in full control of whom they share it with is often the best way to proceed. This is the operating assumption in healthcare records too.

Nailing down copyright licensing is a good backstop if other things go wrong, but the tactics need more work.

Join the OASIS TC discussion list and visit civics.com to continue the discussion! They're working on the TC charter proposal now, and is looking for proposers. They plan to launch in June.

Main Page

2012-06-13T13:40:04Z

WikiSysop: Undo revision 5596 by Stecyk11 (talk)

Personal Cloud work

2012-06-13T13:36:29Z

WikiSysop:

'''Session Topic:''' Personal Cloud Special Interest Group (W3J)

'''Convener:''' Johannes Ernst

'''Notes-taker(s):''' Joaquin Miller

'''Tags for the session - technology discussed/ideas considered:''' ‘Personal Cloud’

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

The goal of the session was to nucleate a group of folk who want to spend some time this year (and perhaps beyond) puzzle out what we actually mean by ‘personal cloud’ and how we can contribute to bringing that about.

One participant drew a picture of what they are building. Others contributed refinements to the picture.

Readers of these notes should expect to hear more about the setting up of some way for such folk to work together.

When there is a better place, a link will also be added at the IWW session page:

[[http://iiw.idcommons.net/Personal_Cloud_work IIW XIV W3J Personal Cloud work]]

What is a Personal Cloud?

2012-06-13T13:32:25Z

WikiSysop: Undo revision 5586 by Joaquin (talk)

'''Session Topic:''' Attempt to reach some consensus what a personal cloud might be.

'''Convener:''' [http://upon2020.com/ Johannes Ernst]

'''Note-Taker(s):''' Johannes Ernst

'''Discussion notes:'''

Personal Clouds are to cloud computing what the Personal Computer was to (mainframe-based) computing at the time: in the mainframe world, a central group of people (the computer operators) would deliver the apps they choose, with the data they controlled, with their terms of service, to users who had to use whatever was given to them. The Personal Computer with personal productivity apps such as spreadsheets was the counter-trend, which put all aspects of computing in the hands of the users, who could add and remove hardware, create, delete and modify data at will, run whatever apps they chose on whatever data they had.

Cloud computing today is largely the same as mainframe computing was back then: a central group of people (the operators of SaaS apps such as Facebook or Salesforce) decide which features to give to users. They can change features at will without requiring the consent of their users (e.g. Facebook timeline, no way of not using it), who control the user's data and often make it hard to move the data somewhere else, or even access it from somewhere else (e.g. no Google crawling of Facebook) and subject to their terms of use. E.g. Facebook or Google can unilaterally ban users and delete their data, which they have done.

Personal cloud computing puts control back in the hands of the users, but this time in a cloud / networked environment.

There are three major parts of personal clouds:
<ul>
<li>data</li>
<li>capabilities (aka apps)</li>
<li>terms and governance</li>
</ul>
For the cloud to be personal, the owner of the personal cloud must be able:
<ul>
<li>to choose and remove the apps they run on their personal cloud</li>
<li>to control who does and does not get access to the data on the personal cloud.</li>
<li>to process data created with one app with another in a similar way as files on a PC may be opened by apps from a different vendor (something not possible with SaaS today)</li>
<li>to set the terms of use themselves of the personal cloud</li>
<li>to move the personal cloud from one host / infrastructure / hosting provider to another if needed (e.g. from an Amazon cloud server to a Rackspace one)</li>
</ul>
Cloud computing features such as replication, and high-availability features should be available. Backup must be available.

Contrast to what some people called "personal data centers" -- set of computing resources some people (usually techies) have control over at home or work. This wouldn't be cloud computing because in cloud computing, somebody else takes care of failing hard disks etc.

Personal clouds interact with each other as peers. So we don't believe that Dropbox etc. are personal clouds. They are just a service that might be used by somebody as one component of a personal cloud.

Personal clouds require persistent identifiers / identity that can be allocated and asserted in a decentralized manner.

May be difficult to communicate because many people do not understand the difference between data and apps.

It's a matter of control and portability.

Today mobile devices are tethered to service providers. This creates a dependency on service providers that is undesirable for personal clouds. Of course it is a reality that some technologies today are only available tethered, e.g. iPhones.

There was 90%+ agreement in the room that 5 or 10 years from now, most people will have personal clouds.

Using DNS ENUM

2012-01-23T11:34:42Z

WikiSysop: Reverted edits by SamElliott (talk) to last revision by WikiSysop

Issue/Topic: Using DNS and ENUM for Identity Management

'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW10] May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes]

Monday – Session 1 - E

Convener: Esther Makaay

Notes-taker(s): Leon Kuunders

'''Tags:''' #ENUM #DNS #domain-names

'''Discussion notes:'''

The mentioning of ENUM in the title triggered a specific response from some attenders. They were interested in what was going on with ENUM and a summary of the developments in the last two years.
However not everyone present had knowledge about the subject, so we started off with a description of Public User ENUM.

With Public User ENUM you can register your telephone number as a domain name. E.g +31 802233445 → 5.4.4.3.3.2.2.0.8.1.3.e164.arpa.
With this domainname, you can publish a plethoria of other contact options, e.g. an e-mailaddress, skype account, SIP account, IM, and many more. Telco's are generally not enthousiastic about this, because it changes their monopoly stronghold (you could circumvene PSTN if you know someones SIP-address).

The domain name isn't registered on a first-come-first-serve basis. Only the person or company using the telephone number is allowed to register the number. The registration is periodically validated against the number and its user.

In The Netherlands, we've seen some use cases emerge that were inspired by ENUM, but drift in a different, identity-related direction. The idea was that if you put contact or reachability data into the domain zone, you could also put other kinds of information in the zone. This could be additional information about the phone number (the domain name) or information about the user of that number.
You could point to a website-URL containing invoicing information or an employee record (with restricted access).

The next step was to think about different domain names. Because you don't per-se need an ENUM-domain, you can do this with any registered domain name. You could work with employeenumber.idm.company.org and only publish the records on your internal network (many companies work with internal DNS servers). You can run your own 'registry' this way.

You can publish information through the domain name, or point to a data source containing more information, like a database, website or server. Although all information in DNS is public, the data source can have restricted access.

Leon is working on a use case to give employees from different departments (physical and organisational) access to each others work environments by working with their employee numbers in a domain name. Since all departments use MS LDAP, it's easy to put that information into the internal DNS servers. The DNS network is already deployed and in use (big overstacked servers that now hardly see any load). Each department can maintain their own information and decide what to publish.

This, as Dave Crocker pointed out repeatedly, shouldn't be called ENUM anymore. ENUM refers to a set of IETF-protocols that are described in RFC 3761 and anything that deviates from this (especially if it deviates this far) simply isn't ENUM. The definition of ENUM should be very precise and there's already lots of discussion going on about the narrow definition (eg in the E2MD IETF wg). Semantics are important!

The conversation dispersed into a broad range of topics, most of them concerning the technology involved.
* Does a telephone number resolve to a person or a place?
* Use a particular reference mechanism from your records (concepts/schema's)
* Business case based on making your IDM implementations more flexible. Also inspired by Phill Windley's “Digital Identity” fourth level of IDM: integrated IDM, IDM is on the infrastructure level.
* Is this mapping to an IP-addres? DNS is based on a string of names. Traditionally it maps a domain name to an IP address, but a lot of its current usage has to do with pointers that do not (directly) resolve to an IP-adress.
* Why not use XRI (discovery protocol)? Doesn't that solve these issues already? But everything already uses DNS. What's the current penetration of XRI? The main advantage is to use the infrastructure that is already there.
* Is the way you get a result from your DNS server rich enough to uses this actually?
* Are domains and e-mailaddress sufficient as an identifier? Most people have multiple e-mail addresses. Why not use iNames as persistent identifiers?
* XRI, XRD, Webfinger → should ENUM be integrated with these discovery protocols?
* DNS calls on the weblayer is that possible? (Javascript sandbox)
* Does this relate to E2MD discussions? → The telephone carriers are talking about adding attributes as well. (Calling party name, number not in use, attributes needed for handling calls via IP on an infrastructure level.)
* What about security? → DNSSEC!
* What about privacy? This depends on your use case, but you should be aware of the public character of DNS and the possibilities to use internal/private networks (like with private ENUM).
* Telnic works with its own references, is this a standard to follow? Again, depends on the use case. Telnic works with TXT records for labels to go with the contact information (eg work phone, mobile phone), uses extra address and naming fields and works with encrypted records for restricted information (only friends can decrypt).
* How can you make sure the identifiers will be unique? DNS will only work when unicity is guaranteed? Domain names are unique on the internet.
* Not everyone has a domain name. Situations differ across different countries in the world. If you don't 'own' your domain name (or a delegation), then you have no guarantee of the availability of the name as an identifier. Has also to do with the maturity of the internet space (eg in the early days, all websites resided under the providers domain). If there is need and usage for owning your own domain, it will happen.
* How does somebody who does not have your phone number find you? people have telephone numbers, e-mailaddresses, domain names
* Laws about portability of mobile phone numbers. There is not such a thing for e-mail.
* Phone numbers are very public, how do you control access to this? You don't (DNS is public), but it's a voluntary registration. It's different from handing out business cards of course, but the DNS is not a database-lookup system. You cannot do “select * from .com where domain like thisname”. You can only look up records with a domain name, not the other way round.
* It would be possible to shield information by using proxies.
* Validation of regular domain names could be helpful for building trust. Validate the WHOIS credentials of the registrant of a domain name. Is this the same as the ex-tended validating from certificate providers? No, those validations apply to SSL-certificates that are used for websites. Validation of a domain name extends to all use of that domain name (eg with e-mail).

The ideas around using DNS and ENUM are very interesting, but since there's so many technical aspects involved (discovery, identifiers, reference-schemes, pointers, usage), it easily gets over-complex and confusing.
In the end it was decided that Esther will (try to) describe the subject in a tight non-technical manner. It should help to simplify the subject if we leave the technology (however interesting) for a later stage.

Certifying Open ID, IdPs, RP

2012-01-19T12:18:39Z

WikiSysop:

'''Session:''' Wed Session 3 Space B

'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW 10] May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes ]

'''Convener''': Eric Sachs

'''Notes-taker(s):''' Eric Sachs

'''Notes:'''

'''Trusted Email Profile '''

Use case: Many websites with a large installed-base of accounts that login with Email & password would like to become OpenID relying parties. However they only way to support IDPs who provide a higher success rate then their current approach for both registration and login rates. Instead of each website identifying those IDPs, they would like a central neutral organization like OIX to maintain a list of IDPs who meet certain known requirements. The following profile lists those known requirements.
 
The IDP must:
* support a PAPE request to indicate that the IDP's assertion should follow this specific certification profile
* meet all requirements of the GSA OpenID ICAM Profile except the requirement to avoid sending PII to the RP
* use an authentication scheme that is at least as strong as the suggested best practices for the ICAM profile
* have a historic 99.5% uptime of its authentication and OpenID IDP system
* NOT require the RP to pre-register with the IDP or enter into a legal contract with the IDP to use that IDP API (similar to the model of SMTP)
* support OpenID discovery based on either the domain name (using directed identity) or an Email address in that domain (using webfinger)
* support AX requests for the AX "email" parameter and return that parameter on every request, even if it has not changed
* only return the email address that the logged in account receives over the open Internet via the IDP's SMTP service (and thus is equivalent to traditional email validation)
* return a global, unchanging and non-recycled OpenID claimed URL for the account
* show at most one page in 99% of the consent flows once the user is authenticated
* default to NOT requiring the user to re-enter their password during the OpenID flow if the user had already been authenticated by the IDP before the OpenID request was made
* default to auto-approving future logins by a user to the same RP
* support checkid_immediate
* support the PAPE openid.pape.max_auth_age parameter, though it can choose to always re-authenticate the user no matter what value is passed in that parameter
* auto-detect mobile and non-JS browsers and show consent pages that a friendly for them

Note Form

2011-10-08T12:43:12Z

WikiSysop:

[[File:IIW_13_Notes_Taker_Form.odt‎]]

[[File:IIW 13 Notes Taker Form.doc]]

Note Form

2011-10-08T12:42:55Z

WikiSysop:

[[File:IIW_13_Notes_Taker_Form.odt‎]]
[[File:IIW 13 Notes Taker Form.doc]]

File:IIW 13 Notes Taker Form.doc

2011-10-08T12:40:12Z

WikiSysop:

XRI

2011-02-07T14:46:57Z

WikiSysop: Undo revision 2944 by Igiwydijok (Talk)

= What is XRI? =
XRI (Extensible Resource Identifier) is a new open standard for digital identifiers from OASIS (home of SAML, WS-Security, WS-Federation, ebXML, XACML, and many other XML standards). XRI has been under development since 2003 by over a dozen companies and organizations including AMD, AmSoft, Boeing, Booz Allen Hamilton, Cordance, ooTao, NeuStar, NRI, PlaNetwork, Visa International, and XDI.org.

= What is XRDS? =
XRDS (Extensible Resource Descriptor Sequence) is the simple XML file format developed by the OASIS XRI Technical Committee for discovering the services available for a resource. XRDS is used by both XRI resolution and [http://openid.net OpenID] discovery, and works with both URLs and XRIs.

= How are XRIs different from URLs? =
XRI is “XML for identifiers” – a language for expressing rich, structured identifiers just like XML enables expressing rich, structured documents. XRIs are compatable with today’s Web but offer some new features most URLs do not have:
* XRIs typically come in pairs – a human-friendly “i-name” and an unchanging “i-number”. This allows the name of a resource to change over time without breaking links (because links can use the permanent i-number).
* XRIs are portable across domains, i.e., a user or a business can “take their XRI with them” to any site or application that uses XRIs – you don’t need to register a new username or address.
* XRIs are “composable” – you can build XRIs from other XRIs like lego blocks (and human language). You can even build XRIs out of other identifiers (URLs, phone numbers, email addresses, etc.)
* XRIs are fully internationalized, so they work in all languages.

= What problems does XRI solve for users? =
'''Simplicity, portability, and privacy.''' A personal XRI like '''=drummond.reed''' or '''=web*terry''' is the first Internet identifier designed explicitly for personal digital addressing – a persistent address for '''you''' (not your devices) that's easy to remember and type, useable for all types of services on the net, portable across all types of sites and applications, and protected from spam, phishing, and data leakage.

= What problems does XRI solve for businesses? =
'''Intelligent resource identification.''' From a business point of view, XRIs are to URLs what fax numbers are to ordinary phone numbers. As digital data sharing protocols like OpenID, SAML, and XDI gain adoption, a business XRI like '''@cordance''' (and the underlying i-number) will become their universal “web services number” – one that keeps working no matter how often they move, change names, reorganize, merge, etc.

= What problem does XRI solve for everyone? =
'''Universal tagging.''' XRI is the first digital addressing standard explicitly designed to include ''tags'' — generic identifiers like '''+budget''', '''+home''', '''+phone''', or '''+poodle''' that everyone can use to describe resources in a way both people and machines can understand. And because XRIs are composable, even XRIs themselves can be tagged.

= What software supports XRIs today? =
XRI support is included in [http://openid.net OpenID 2.0], specifically to use the '''XRDS (Extensible Resource Descriptor Sequence)''' service discovery format and to solve the ''OpenID recycling problem'' (having someone take over your OpenID because you lose your username or domain name). The [http://www.eclipse.org/higgins/ Higgins Project] uses XRI for data addressing, and XRI is the basis for the OASIS XDI data sharing protocol. There are two open source XRI resolver/server projects – [http://dev.inames.net/wiki/OpenXRI OpenXRI] (Java) and [http://xrisoft.org/ Barx] (Ruby).

= Where can I register an XRI? =
XRI registries come in three types: global registries (similar to DNS top-level domains), community registries (similar to DNS delegated domains), and peer-to-peer registries. Global registries are operated by [http://www.xdi.org XDI.org], an international non-profit public trust organization. XDI.org hosts a list of the [http://www.inames.net/register.html XDI.org Accredited I-Brokers] accredited to register global i-names for a fee, just like registering a domain name. Free community i-names are available from s number of XRI community registries such as [http://xri.net/@freexri @FreeXRI] and [http://xrid.net @xrid]. Peer-to-peer registries can be created using the XRI server software from XRI open source projects such as [http://dev.inames.net/wiki/OpenXRI OpenXRI].

= Where can I go for more info? =
The three best sources are:
* [http://en.wikipedia.org/wiki/XRI The Wikipedia page on XRI] - overview and links to many resources.
* [http://dev.xri.net The dev.xri.net wiki] - especially tools for developers.
* [http://www.oasis-open.org/committees/xri/ OASIS XRI Technical Committee home page] - links to the specs, FAQs, and other technical docs.

Also feel free to contact members of the XRI community listed in the [http://dev.xri.net/wiki/About_Us dev.xri.net directory].

XRD Provisioning

2011-02-07T14:42:28Z

WikiSysop: Undo revision 3255 by Igiwydijok (Talk)

Tuesday – 1 - G

'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW 10 ] May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes ]

Convener: Jared Hanson

Notes-taker(s): Jared Hanson

A. Tags for the session - technology discussed/ideas considered:

B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Links: http://xrdprovisioning.net

Topics:
How to identify the link?
* use the xml:id attribute or the href:type:rel tuple
* href:type:rel should be good enough but xml:id is the purist solution
* consensus to use the xml:id to identify the link rather than matching the href:type:rel tuple
* the POST of the <Link> can request a particular xml:id but the service can override the xml:id and return it to the caller

Ownership of who is allowed to update which links
* Use OAuth to protect the REST APIs
* proposal to add an extension element "dc:owner" to the actual link element

Is there a need to identify what the protection mechanism is?
* maybe a separate doc to map to HTTP Basic or OAuth
* leverage the WWW-Authenticate header to identify how the

Need to make sure that an attacker CAN NOT update someone else's <Link>
* this is a critical security requirement

Request to support a form-encoding mode for simple addition of links
* only support for limited <Link> elements

JRD should be out of scope for now
* eventually make it an optional encoding

Define a rel type to represent a visual editor for the XRD
* defines a relationship between the user and their user management page

XDI

2011-02-07T14:42:24Z

WikiSysop: Undo revision 2946 by Igiwydijok (Talk)

= What is XDI? =
XDI (XRI Data Interchange) is an emerging structured data sharing protocol from OASIS based on the XRI structured identifier standard (see the one-pager on [[XRI]]). It has been under development since 2004 by many of the same individuals and companies working on XRI.

= How is XDI different from conventional XML? =
XDI is a new approach to data sharing that does for machine-readable data what HTML or PDF does for human-readable content: puts it into a standard format any XDI-enabled system or application can read. This is a very different approach than conventional XML, where each XML document uses its own schema (way of identifying and describing the data it carries). By contrast the extremely simple XDI schema is standard across all XDI documents. The key is that every item of data, from the smallest atomic field to the largest multi-terabyte database, is identified, described, and linked using XRIs.

= How is XDI different from RDF? =
As explained in [http://wiki.oasis-open.org/xdi/XdiRdfModel The XDI RDF Model], XDI ''is'' RDF. Technically it is an RDF vocabulary. [http://en.wikipedia.org/wiki/Resource_Description_Framework RDF (Resource Description Framework)] is the basis for the W3C’s Semantic Web initiative - a set of standards for expressing metadata (data about other data) that enable machines to more intelligently and efficiently find and process information on the Web. XDI is a highly optimized form of RDF designed for cross-domain data sharing. XDI documents typically use a compact serialization format called [http://wiki.oasis-open.org/xdi/X3Format X3] (very similar to [http://www.json.org/ JSON]) that is much simpler and more streamlined than RDF XML. However all XDI documents can be instantly transformed into RDF XML documents if needed. See the [http://graceland.parityinc.net/xdi-converter/XDIConverter XDI Converter] for examples.

= What are XDI link contracts? =
Because of the 100% addressable shared graph model, XDI documents can be used to control the sharing of other XDI documents. These are called '''link contracts''' because they serve the same purpose as real-world contracts (e.g., a non-disclosure agreements) that define who has access to what data for what purpose. Link contracts are an Internet-scale solution for authorization, access control, and data rights management.

= What problems will XDI solve for users? =
'''Data portability and protection.''' A primary application of XDI is to make personal profile information – anything from contact data and travel preferences to financial data and medical records — portable across websites and applications everywhere. Think "PDF for personal profile data". The combination of XDI data portability and XDI link contracts can give users significantly greater control over sharing and usage of their personal data.

= What problems will XDI solve for businesses? =
'''Automated data sharing and user-centric data management.''' XML has already been a boon for data interoperability and service-oriented architectures. XDI is the next evolutionary step. By adopting a common data sharing format and Internet-scale data addressing model, XDI can automate many common data sharing and integration operations that currently require much more expensive solutions. XDI also enables bridging the worlds of personal, social, and enterprise data sharing while helping ensure that the proper data is always shared and managed in the proper context.

= What software supports XDI today? =
The OASIS XDI standards build on the OASIS XRI standards, the second generation of which was just completed in spring 2008. The first formal XDI specifications are expected in early 2009. However there is already an open source implementation of the [http://wiki.oasis-open.org/xdi/XdiRdfModel proposed specifications] called [http://wiki.eclipse.org/XDI4j XDI4J (XDI for Java)]. Visit its [http://graceland.parityinc.net/xdi-validator/Other.jsp demonstration site] for complete set of simple XDI applications and utilities.

= Where can I go for more info? =
Start at the [http://en.wikipedia.org/wiki/XDI Wikipedia page on XDI]– the XDI community uses this to maintain current links to all relevant resources. And read the [http://wiki.oasis-open.org/xdi/XdiRdfModel The XDI RDF Model] document from the [http://www.oasis-open.org/committees/xdi OASIS XDI TC].

Where should Identity Live

2011-02-07T14:40:21Z

WikiSysop: Undo revision 3291 by Igiwydijok (Talk)

'''Convener:''' Andrew Arnott

'''Note-taker:''' Hannes Tschofenig

'''Tags: ''' Identity, IdP, service provider, token, assurance

'''Discussion notes:'''

'''Definitions'''
* ''Entity'' - A person or device that should be discernable from another.
* ''Identity'' - the minimal data necessary to discern between entities in a given context.

Terminology taken from ISO/IEC JTC 1/SC 27 N7751:
 entity: something that has a separate and distinct existence

'''identity:''' total list of attribute values of an entity that allows this entity to be distinguished from other entities within a context and to be recognized in that specific context

some term needed for "context".

What identity is not:

Membership: identity is not controlled by an organization, and cannot be revoked by an organization. Membership or authorization may be revoked by a controlling party, but that is not identity.

Authorization or (necessarily) access control: although an organization may control access to a resource, they do that by assigning or revoking privileges to an identity, and not by revoking privileges to assert that identity.
Ideals in identity

Roamability of the client: (most) users MUST be able to log into (most) services from any geographic place and from any device. An entity's possession is not always a requirement.

Portability of the IdP: The identity asserting service or device MUST be able to transfer that capability of assertion to another service or device. Or Limited delegation of authority.

Rights of assertion: (some) users are willing to empower a trusted third party to assert their identity without aid of another party or device. Some services require multi-factor authentication. Some users will prefer to spread out rights of assertion, such that an IdP and a physical user token are required at the client in order to assert an identity at an RP. Perhaps users will fully empower one IdP, while only partially empowering another.

Multiple identities (persona): (some) users want or need to maintain multiple identities for individual services in order to avoid correlation or separate tasks.

Correlation of identities: some users want to correlate their identity across services. Some services want or need to correlate the identities of their users. Some users do not want services to be able to correlate their identity across services. Some sites MUST NOT be able to correlate their users' identities across services.

Phishing protection: identity SHOULD NOT be phishable. It's not that we mitigate against profitable phishing -- we make it impossible by using non-phishable credentials wherever possible. (non-correlatible)

Verifiable assertions: An identity assertion can be verified by a service without a need to trust the IdP that sent the assertion (the IdP may not be the signing entity), and possibly without a network connection. Checking various identity revocation lists, if supported by a particular service, would require at least periodic updating of a cached list or a network connection.

Non-collision of identities: an identity must be globally unique.
Revokable only by entity: an identity, once created, can only be destroyed (or rather, the ability to assert that identity can only be destroyed), by the owning entity. The creator of an identity may also create a power of revocation that may be assigned to the entity, allowing the entity to terminate a compromised identity.

Temporary revocation: Some entities may lose control of their identities (lost cell phone) but later recover it.
Non-transferrable: Roles are transferrable -- not identity. Identities MUST NOT be reassignable to others, especially by accident. (exception: perhaps an organization does not want to expose that a change in the person filling some role has taken place).

Non-enumerable: if a physical token maintains a user's identities and the services the user is a member of, physical access to that token should not enable someone to enumerate the services the user has come in contact with.

Non-repudiation: (some) services may need to be able to prove that an identity was asserted to it. (some) users may need to prove that they visited some service.

Level of assurance: Some services demand a certain level of assurance that an asserted identity is indeed originating from the owning entity.
Practical details

Identity may have metadata (attributes) associated with it (i.e. membership, roles, authorization, signed claims). Services may store metadata about an identity within the service, or may publish metadata to a shared service for which access control may be set, perhaps with user consent.

These public identity-metadata correlation services may provide a service to search for identities with metadata that matches some criteria, thus allowing people to easily find identities based on traits known about a known entity.

Some services do not need identity at all, but only claims (membership, roles, or other metadata) signed by a trusted identity in order to provide services to other entities.

Risks

Denial of service: An evil entity that gains temporary control of an identity may obtain a revocation for that identity, which the evil entity may issue at a later date, after the identity's rightful entity regains control of that identity.

Denial of service: A disruption of a service's means to verify new identities.

What does and RP need to survive compromise of user@idp?

2011-02-07T14:40:17Z

WikiSysop: Undo revision 3211 by Igiwydijok (Talk)

'''Conference [[Notes_iiw8|IIW8]] Room/Time:''' 10/B

'''Convener:''' Luke Shepard and Breno

'''Notes-taker:''' Bill Shupp

'''Attendees:''' Luke, Breno, Allen Tom, Bill Shupp, Anthony Eden from chi.mp, lots of others

'''Technology Discussed/Considered:''' OpenID

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

Key understanding: An RP needs a way to communicate to the OP that it has been compromised, or perhaps request from the OP when the last time credentials for that user changed. This is necessary so that when an RP blocks an account, it knows when the account has been “reset” at the OP.

Outstanding questions are where this fits in the protocol, and how this data is communicated from the OP to the RP. Suggestions included modifying nonces to expose it, adding an optional request parameter to checked_* modes to expose this, and abstracting the data do “credentials change more/less than X time ago”.

Here are the unedited notes taken during the meeting:

What does a RP do when user@idp is compromised?

*What tools does the RP need when this happens?
*User/Pass logins usually reset a password and send an email notification. Not available in OpenID.
*Do you add additional PAPE levels after a compromise has been repaired?
*Should OPs provide a security endpoint?

*What's the value of resetting the password?
**Email + OP providers have less value
**Password reset is still useful, even if it doesn't solve this case
**It's useful to separate the attacker from the user
*Another attack scenario is when an attacker phishes an account, then sets up an OP to link to the account, providing a backdoor (worse case)

*If your account was created with OpenID only
**Communicate with the user directly if AX/SREG provided an email
**Create a communication mechanism with the OP
**Other mechanisms for identifying the user, send one time pass to cell phone

*Does the RP want the responsibility of extra credentials? Or does the RP want a cooperative approach with the OP?
**If OPs are notified, the attacker (as OP) could collect data on the RP's process/state

*Should there be a way of exposing to RP the last credential change time at OP?
**Could be a nonce based on the state (within PAPE?)
**Should there be a history of changes?
**OPs should have flexibility around how much information to expose

*Should we be trying to arbitrarily put trust data in the protocol?
**RPs need concrete, objective measures to know that a password/credentials reset has occurred at the OP
**OP could certainly lie about it, but including a date could be useful

*How is this credential change communicated to the OP?
**In checkid_setup?
**Should the OP just provide this data in each response, so that the RP doesn't need to make the request?

*Response term name.
**Instead of referencing it as "last credential changed", it could be "last time verified good"

*We are interested in short windows of time here. Maybe use ranges? Like "credential change is > 1 day old"
**Optional "older than you care about" value?
**Value is abstract, not concrete.
**OP has the option of not sending this

*Possible flow:
**Do checkid_immediate to see who they are
**If needed, do another checkid_immediate to see when the credentials have changed
**If not satisfactory, do checkid_setup requesting credential change

What are the Business Models of ID Conference

2011-02-07T14:40:13Z

WikiSysop: Undo revision 3370 by Igiwydijok (Talk)

'''Conversants:''' Kaliya Hamlin, Louie Gasperini, Stephen ''who works with Phil''

We talked about the lack of business people at the conference and the NEED to figure out the business models.

We thought a highly focused 1.5-2 day event this winter could help move this conversation forward.

We decided to go forward with an invitation and finding a place. Likely dates are late Feb early March.

Likely place in the mountains.

XDI and RDF Graph Model

2011-02-07T14:37:05Z

WikiSysop: Undo revision 3231 by Igiwydijok (Talk)

'''Session:''' Wed Session 5 Space A

'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW 10] May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes ]

'''Notes-taker(s):''' Markus Sabadello, Cameron Hunt

'''Notes:'''

I think nobody took notes, because pretty much everybody in the session was somehow involved in holding it :)  

Well yes we went over some of the similarities and differences between XDI and RDF. Here is a quick list that is greatly simplified, but maybe it would be useful for the notes:  

What the models share: 
* Semantic data, organized in triples, forming a graph 
* There are "resources" and "literals" 
* Various ways of querying and reasoning exist  

Where they differ: 
* In XDI, there are semantics not only in the graph, but also in the identifiers (e.g. $v$1) 
* XDI has XDI messaging, RDF has SPARQL, Linked Data, FOAF+SSL 
* XDI has built in access control (link contracts) 
* RDF has blank nodes, XDI has inner graphs 
* RDF has ontologies, XDI has dictionaries 
* RDF can have multiple literals per subject/predicate, XDI only one 
* XDI can use persistent identifiers (i-numbers)  

Regarding a bijective mapping between XDI and RDF, this is a topic that has haunted Drummond, Paul and me for years.. The short story is that a quick mapping is extremely easy (because in both models you just have triples), but the more "complete" you want the mapping to be, the harder it gets.  

Such a mapping is actually implemented in several Higgins components. See here for a glimpse at this endeavor: http://wiki.eclipse.org/IdAS_XDI_Mapping  Markus

'''''Cameron Hunt's notes:'''''

Honestly, I started to take high level notes, but pretty soon I was jumping in (and up - using the white board). The discussion was pretty brief, and really just gave a high over view of XDI, then I responded with how those same things are being addressed by RDF-oriented solutions.

Specifically, while RDF alone certainly doesn't cover the broad capability set provided by XDI the Linked Data/SemWeb crowd is using RDF-oriented methodologies (SPARQL, Linked Data, FOAF+SSL, and even the proposals for RDF2) that claim to address those same sets of capabilities.

And while there are some pretty strong personalities that are difficult to engage, even those personalities are on record as claiming that the principles are more important than the implementation.

I myself (thanks to Randy) learned about the key weakness of FOAF+SSL (it doesn't separate the access token from the authorization token) - but I think there are some folks working on FOAF+SSL in particular and SemWeb/Linked Data in general that might be open to dialogue - I'm thinking in particular of Nathan (http://webr3.org/blog/) who is actively involved in those spaces.

XRDS for OpenID and Information Cards

2011-02-07T14:37:01Z

WikiSysop: Undo revision 3357 by Igiwydijok (Talk)

Convener & Notes-taker: Axel Nennker

'''Technology Discussed/Considered:'''

XRDS, Open ID, Information Cards

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
'''

We should use XRDS (Simple) to let a RelyingParty/OpenIdConsumer/Resource/Service express its needs and the services it provides.

Something along these lines is describes here http://ignisvulpis.blogspot.com/2008/10/information-cards-with-xrds.html

* The relying party (https://xmldap.org/relyingparty/) provides a HTML LINK-rel element in the html code.
* A browser extension finds the LINK element and downloads the XRDS document the LINK points to.
* The browser extension looks for service types it is willing to support
* In the case of Information Cards it retrieve the "policy" of the relyingparty
* If the user now chooses to start the card selector the applicability of a card is governed by the RP policy.
* After the security token has been generated it is send to the RP service endpoint listed in the XRDS document.
This transfers the user's credentials/claims aka "security token" to the RP.

What we should agree on in this session is a set of XRDS types that are suitable for OpenId.

First here are the things for Information Cards:

* http://infocardfoundation.org/policy/1.0/login Describes where the policy can be retrieved.
The scheme in the Uri part of this services SHOULD be https.
* http://infocardfoundation.org/service/1.0/login Describes where the security token can be posted to.
The scheme in the Uri part of this services SHOULD be https.

What is needed for OpenId?

* http://openid.org/policy/1.0/login
* http://openid.org/service/1.0/login

If these two XRDS types are accepted what is the "policy"?

What an RP Needs

2011-02-07T14:35:14Z

WikiSysop: Undo revision 3190 by Igiwydijok (Talk)

http://www.slideshare.net/jsmarr/what-an-rp-wants-part-2

'''What an RP Wants - Part II,''' Joseph Smarr, 11/02/09

'''What we said in February'''
* Hybrid OpenID/OAuth is a game-changer
* Plaxo/Google integration proved the “Chasm of Death” can be crossed
** 92% success rate
* We need all the major players to become first-class OpenID Providers (OPs)
* More user data (profile/email + contacts)
* User-friendly (not scary) consent UI
* Auto-login on return (checkid_immediate)
* Commitment to do what it takes for both sides to be successful
* What’s happened since(ship early & often)

'''What’s happened since'''
* Faceboook became an OpenID RP and joined the OpenID Foundation
* Plaxo built a deep 2-way integration with Facebook (using Facebook Connect)
* MySpace rolled out full Hybrid/Open Stack (though without validated email address)
* Microsoft declared they’ll do OpenID for real (though were vague on timing)
* Yahoo rolled out Hybrid.

'''What hasn’t happened since'''
'''''Still waiting for more great OPs'''''
* Facebook (Hybrid RP)
* Microsoft (Doing OpenID, but OAuth?)
* AOL (OpenID, but not 2.0 or Hybrid)
* Twitter (OAuth, but OpenID?)
* Plaxo (Hybrid RP and PoCo Provider)
* LinkedIn (?) Still waiting

'''''So, where do we stand?'''''
* Significant progress, though more slowly than we might have hoped
* But the fact is, I cannot recommend a new startup bet their business on being an RP. Why?
* Still a bunch of unsolved issues and un-met needs… for more great OPs

'''What an RP Wants - nope.... What an RP NEEDS.'''

'''''More high-quality OPs'''''
* Desktop / mobile / API best practices
* Solution to the “Nascar problem”
* Confidence that RP users are 1st class
* Virtuous cycle

'''Desktop / mobile / APIs'''
* OpenID login is a web-only solution
* As an RP, how do my users log in to:
** My rich desktop client
** My iPhone app
** My REST API
** My TV widget
* Option: use OAuth flows as a bridge
* Pop a browser for OAuth flow
* Log in using (web-based) OpenID
* Need some way to tell the client to continue
* Option: direct auth API proxied to OP?
* Simpler UI, but assumes username/passwod
* Do this for all users, or just RP users?
* Consistency vs. complicating the base case

'''''Solution to the “Nascar problem”'''''

'''''Solution to the “Nascar problem”'''''
* How many buttons?
* What about smaller OPs?
* What to do for return users?
* Visits from other computer?
* E-mail addresses as IDs?
* What about OPs that aren’t webmail providers

'''''Confidence in RP users'''''
* Part perception issue, part reality
* What happens when an OP dies?
* If users get trained by login buttons, can I ever move/change them?

'''Virtuous Cycle'''

'''Conclusion:'''
* '''''We’ve still got a lot of work to do.'''''

* Why I still believe…(picture of the community at IIW)

VRM UI Session

2011-02-07T14:32:19Z

WikiSysop: Undo revision 3219 by Igiwydijok (Talk)

'''Convener:''' Doc
'''Attendees:'''
* Joe Andrieu
* Drummond Reed
* John Bradley
* Johannes Earnst
* Nick Glvotovsky
* Judi Clark
* Abby Jenkins
* Greg Biggers
* Mary Hodder
* Hank Mauldin
* Kevin Marks
* Christopher Carfi

Lots of r-button projects in progress
* Iain Henderson's Personal address manager
* Implementation for radio apps / iPhone
* Radio Paradise reference app

Three states; two icons
* Nothing
* Open (actions availabe, none take)
* Closed (relationship action has been taken)
'''
Reason for r-button:''' enable REAL relationships between individuals and vendors/entities; not 'fake' relationships of CRM

Rbutton started as ways to represent relationship

Rbutton specifies (person who marked up page) must represent entity to have relationship with URI the mechanism?

What about in chrome of browser?

What about the variety of entities?

What about scalability if you're polling 100 entities on a page?

Feasibility in practical terms - too much computational overhead?

* Job of Relationship manager = discover all relationship services; contact them; determine if/who I have relationships with
* User Agent uses RM to poll RS for entities
* We don't need a standardized entity ID, but pockets of shared identifiers

You don't need a URI - could be well-formatted XRI/h-card/semantic data about an entity
* A URI could be used as a discovery service rather than UID, showing us which RS's are available

Alternative: Quad-state r-button (only shows one half) - this would show when vendor is at the table vs. just user-driven relationship services.

How is r-button different from an aggregator that figures out preferred online service provider for users? (i.e. r-button is only part of the VRM discussion; how does this really change things?)

Answer: services must be VRM compliant

Outcome: the specific cases for r-button today are not particularly compelling, but are good for describing and specifying

Payment escrow, medical records, and personal RFP is very different from r-button service aggregation and offer a compelling vision of the future use of a distributed, user-driven relationship ecosystem
* Three groups of RS's (vendor, user, third-party)

'''TWEETS & PICS:'''
@drummondreed whiteboard of how relationship discovery works for rbutton entity relationship services #vrm #iiw2008b http://twitpic.com/lecm

Quad state r-button vs tri state r-button photo #VRM #IIW http://twitpic.com/ldmn

Verified Claims

2011-02-07T14:32:15Z

WikiSysop: Undo revision 3290 by Igiwydijok (Talk)

Canonical use case: proving you are over 21, you are a frequent flyer gold member, etc. (see Dick Hardt's Identity 2.0 video)
 
University of Washington:
* proving student status so that they can get deals from companies, e.g. download software from Microsoft
* lots of other educational use cases: prove student graduated, transcript, faculty status
* a bunch of universities have agreed on a common schema format
* why not just verify email domain? Email namespace aren't all students, only a good approximation
* how do you deal with appeals: i am a student, but the system doesn't verify me correctly. There are lots of edge cases, always need customer service.
 
Charles Schwab:
* Want to see if they can accept openid or info card, but how can they trust claims? Worried about user's country of origin, credit history, terrorist list.
* Can we leverage a charles schwab account (which has pre-verified a bunch of attributes) and use it elsewhere?
* Can we make it easier to create a charles schwab account using verified claims elsewhere?
 
beenverified.com
* example of a startup trying to intermediate verified claims
* costly and unclear why RPs should trust this site
 
Other Topics:
* How long should claims be valid for? Do we need continual audits (e.g. elevators / gas pumps audited regularly). Depends on cost model, e.g. if insurance is expensive, maybe can afford to do regular audits.
* Assertions can be "local" -- institutions will be different depending on where the user is. (e.g. US has DMV, but other places may not.)
* Some folks looking at leveraging trusted sources of social data. Allow user to e.g. claim linkedin profile, facebook profile, etc and generalize that to a credential.
* Story about the lack of credentials in Wikipedia. SJ claimed to be professor of comparative religion and won a bunch of edit arguments. When he took up a job at wikia, he had to reveal himself (24yo).
* How do we trust claims -- how do we know some party is authoritative? How do you verify security of the entire stack, down to network and device level?
* We need common schemas for verified claims, to be used with openid/saml, etc.
* We need out of band agreements between RP and authoritative verifier
 
 
- Vince Wu (vwu@google.com)

Vulnerabilities in ID tech

2011-02-07T14:32:11Z

WikiSysop: Undo revision 3072 by Igiwydijok (Talk)

'''Vulnerabilities and Weaknesses in Identity Protocols'''

'''Convener:''' Rick Smith

'''Notes-taker:''' Rick Smith

'''Tags:''' Information Cards, CardSpace

'''Discussion notes:'''

A little bit of the blind following the blind.

'''Cardspace:'''

User clicks on card selector – transmit to relying party the information.

If it’s a self-issued card, then the client sends it directly.

If it’s a managed card, the data is still sent by the client, but the client sends a token signed by the “manager,” or ID provider.

Cards run in a protected space so that the contents can’t be sniffed by other unprivileged processes.

'''Four risk areas:'''

Native code running on client systems, and/or plug-ins on a browser. Attackers can substitute subverted code and intercept personal memorized secrets that secure the cards, or that are used with IDPs to authenticate a managed identity.

Network based attacks – forged transactions or modified transactions used to spoof identity. Most implementations rely on SSL to protect on these. Not all protocols require SSL in all circumstances where it is needed.

Subverted or malicious relying party – can the RP turn around and exploit the user’s identity to masquerade to another RP?

Spoofed IDP – a variant of the network based attack – can an attacker trick the RP into authenticating a user by intercepting IDP transactions and providing a bogus response

TPM modules – there are 300 million machines with TPMs today – we have a way to install secure software and safely manage crypto keys.

VRM Development

2011-02-07T14:32:09Z

WikiSysop: Undo revision 3023 by Igiwydijok (Talk)

'''Issue/Topic:''' VRM

'''Session:''' Tuesday 2F

'''Conference:''' [http://iiw.idcommons.net/Iiw11 IIW-11] November 2-4, Mountain View, [http://iiw.idcommons.net/Notes_IIW11 Complete Notes Page]

'''Convener:''' Doc Searls

'''Notes-taker(s):''' Gon Zifroni

'''Tags:''' VRM, independence, symmetrical relation, reverse-cookie, demand first, pull, anonymity

'''Discussion notes:'''

Doc Searls starts with a general description of VRM:

You should be in control of the data you generate. In a digital world it is convenient to have all your relations under your control: centrally controlled by you.

> The set of identifiers that give you access to services online.

Problem addressed:
The independence of the individual both independent of anybody else but at the same time able to engage with multiple people.

Iain Anderson of MyDex gave (once) an example that grew out of the kernel of VRM, the change of address. I want to be able to change my address for multiple services at the same time, although various services have single interests in my identity.

*XDI (Drummon Reed)
*PDS
*MyDex
*Information Card (Ms)
*R-card (relationship card)
*Switchbook
*Mine! project
*Kynetix
*Azigo

Iain came up with 4000 variables negotiated within a relationship. There are symmetrical relationships with equal power on both sides. While with asymmetrical relationships you sign a ULA > Web services and business models are anchored on this. "We tell you what the relationship is". You may have a lot more interest about what you buy in the store than they do, but you don't have access to it nor control over it.

Following a question by Susan (Value Networks), Doc gives the example of the loyalty card (green stamps catalog): tracking what you're buying in the store, targeted ads. But they don't know what you actually want, they tell us what we want: intent is not captured.

Joe's response: Game about open systems to being beholden to services. Statement: if an alternative emerges services will adopt it.

Doc talks about multiple pricing schemes to incent buyers to use self-checkout scanning in shops. In a nutshell the history of e-commerce is "1995, the invention of the cookie. The end."

There's more talk about intent "vendors don't know what I want to buy next".

Doc talks about Kynetx: everything is an n point, with an event and a rules-set described by rules-engines.

Joe continues: Kynetx is about augmenting your experience: some of the Google results you might have a relationship with which Google doesn't know about but can be surfaces for you from your end.

Write rules for queries by users/buyers going by shops/stores checking their inventory based on your query.

Supply <> Demand

Routing our intentions: individuals express their demand to generate supply. What's the downside of the store saying they have it? Third party needed to ensure their reputation. If companies are advertising wrong data about their stores: leverage the regulations or social reputation (trust).

Demand <> Supply
* Opposite of CRM where sellers own the relationship with buyers.
* Supply chain automation (question by Ace Swerling)
* Notion that the customer brings a lot to the table
* Reverse auctions example for just in time manufacturing
* Key example is the personal RFP, example of demand driving supply
* Priceline.com, Kayak alerts, consumer type of behavior, LivingSocial, Blippy, Shrout
* Is social the backbone of VRM or not? Are relations the fourth party?
* Joe's comment "Nobody owns email‚Ä¶but it wasn't initially."

The r-button in one configuration can say: "I'm willing to deal with customers on your terms"
With emancyterm both terms (seller, buyer) can be matched up.

Question: Is it similar to ad-exchange? 3 parties: Publisher, Advertiser, User.

Joe says key distinction: the publisher website could have other websites behind it. "You're broadcasting your needs" > Personal generated claim or preferences. Diff with ad-targeting: Groupon is still push from the vendor. The fact that I Like Lady Gaga does not mean that I want to buy the album, I already have it!
(see Reverse-cookie)

Remark: Yes but we tell google all the time what we're looking for, what we want.

Ankit Kapasi: point to point sharing, share within contacts.
> The systems that we have without gesture we find suspicious.

How can we do some of the things we have offline online: offline we have anonymity "I want less identity when I walk into the store". Why can't I take my shopping cart from one site to another?

Problem of this discussion are the commercial examples. Discuss retail commerce without thinking like marketers. Let's try other examples. Why can't I change my credit card when I'm loosing it, while not loosing all your trusted relations?

Kevin Marks talks about how Webfinger helps discovery under the user's control.

VRM Parts

2011-02-07T14:32:04Z

WikiSysop: Undo revision 3253 by Igiwydijok (Talk)

Issue/Topic: VRM Parts and Holes

Monday – Session 5 - E

'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW10] May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes]

Convener: =DOC

Notes-taker(s): Markus Sabadello

A. Tags for the session - technology discussed/ideas considered:

B. Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

*ProjectVRM grew out of IIW
**Individuals should be able to control relationships under their own terms
**Concerned with interaction with commerce and government

*User = Point of Integration
*Change the marketplace where we as customers have more to contribute

*CRM: 12$ billion business.
**"Customers are creatures you hunt, seek, lock in, acquire, manage" = language of slavery used by the sellers of the world

*CRM Magazine: "Customer does not belong to you."
**Change happening in CRM business!

*CRM is not gonna like VRM? VRM = reciprocal? No! Venn diagram, they are part of the same thing. Buyer and Seller both gain from it. Power to all parties.
*Advice to CRM people: Learn from it, take advantage!

*Projects: MyDex, Mine, Switchbook, Azigo, Kynetx, Banyan, etc..

*EmanciPay: For circumstances where there is not already a price, is there a way where we can say "Here is what I would like to pay" ?
**--> Web site owners can put RDFa code on websites that points to where you can be paid
*Mechanism to determine prices on the fly
*Empowers the consumer to say "I want to pay this for that"

*Legal structure in place for VRM?No, but there is a lot of attention, e.g. in Kantara DataSharing group.

*End of phase 1 of e-commerce! (Cookies, absurdly long terms of service, giving all the rights to the seller).

*Can we have a casual relationship with vendors online? Like simply walking into a shoe store, without having to become a member etc.

*European privacy laws more friendly than American ones

*Foursquare TOS: If we're sold, your data will be one of our assets and also sold.

*William explains situation in UK: Issues around ID-Cards, centralized health records, data theft.
*UK government interested to move towards something like VRM. Times are right to propose a working community prototype where government agencies act as relying parties.

*Iain gives example: "Tell us once" program by government. Works, but is run by a government site, not in a user centric way.

*2 important trends for VRM:
**self tracking
**personal informatics

*Powers are becoming more equal, abilities are increasing.

*Need code to move forward.
*Need for figuring out the legal side.

*VRM = extra money for sellers. potential additional customers that want to pay on their own terms.

VRM Loyalty Cards in Real World

2011-02-07T14:31:34Z

WikiSysop: Undo revision 3217 by Igiwydijok (Talk)

Notes from our first VRM session at IIW. Led by Chris Carfi.

(participants please correct or expand)

VRM and loyalty cards.

Chris showed <http://scanaroo.com>, which gives users a way to collect visual versions of their loyalty cards in one app on an iPhone. "Very much a 1.0 product right now." But with lots of potential.

We talked about that potential...

From USER's side, what can be done to improve the experience --

and the function.

WE advertise to THEM.

Expressing needs and wants

BugMeNot for Loyalty.

Shopping cart tracking / time shifted checkout (go through store checking out while moving)

Publishing shopping list exclusively to outfits to which we are loyal through Scanaroo (or the equivalent)

Eport/portability of info

"my history" -- a MINT.com for shopping

"Share a Deal"

* location
* product
* time
* store
* me
* price

vendors could subscribe to user data

Tagging/Folksonomy... XDI-like

Store Map + item location

Subscribe to 1,2 (at price)

The "Doc Searls" (or anybody) loyalty program. Stores are loyal to individuals, rather than vice versa. Leverage ID standards. e.g...

=doc

@dsearls

Concierge/personal shoper

"Find me the nearest X"

Site components (for scanaroo.com or whatever)

Coupons

VRM and Media

2011-02-07T14:31:30Z

WikiSysop: Undo revision 3320 by Igiwydijok (Talk)

'''Conference [[Notes_iiw8|IIW8]] Room/Time:''' 6/E

'''Convener:''' Doc Searls

'''Notes-taker:'''

'''Attendees:'''

'''Technology Discussed/Considered:'''

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

Business model for free media

2 approaches currently

*Sponsorship – big pockets support free stuff.
*Or appeal to the viewers – NPR, etc.

If music – band greenday, radiohead, go to their silo and deal with them in their different way.

Each radio system has its own system

Their fundraising is identical also.

VRM model is Emancipay.

See slides
*Additional to the original grant – not want to have IP issues.
*Want to add value in public domain

Advantage with iphone is single target platform.

*VRM will inform CRM
*The “r-button” provides stance on contributions.

Doing this with information cards – See Craig Burton
Graphical indication of intention relating to interaction.

2 stages – will fan out to other media.

*Listen log – logging system – what have you been listening to. Most stations don’t send data out with their streams. Stations will later want to cooperate in sending out data.
*Data collection associated with the media. Need granularity if will pay for media in a new way. Want to make it easy to contribute to media.

Discussion of funding

Give customers their own pricing guns.
Wanamakers did it after the French.

Emancipay is a pricing gun system. Want to equip individual with means to put money on the table for media and declare what it is worth. Can inform what is there with listen log.

Harder with newspapers. Newspapers could not have approved business plan now. Carbon footprint is an issue with both newspapers and online.

Some want to contribute, but don’t want to be a member. If so, should be able to impose conditions on the contribution.

Don’t want to CRM someone into negativity. Don’t spam someone into the negative.

The main purposes of the log are:

*Information on what you listened to – situated cognition/memory. Without having to search general website.
*Also for let you know what you value – to help you pay, and decide what you like.
*Designing it so that the information is not on the phone.
*Want to be able to bookmark songs, stories, etc. to be able to reference/purchase easily.

If people can see what using, they will value it more, and if make it easy for them to pay they will.

Can folks be tied in but anonymously. Yes.

Can the logs be constructed anonymously? Cannot keep it on the machine currently.
Question of whether can maintain the log anonymously.

Medium providing data that can be used.

Speaking with Apple. They are friendly with the radio community. Apple receives podcasts from NPR and posts them for free. Within iTunes – the hope is that they would provide the symbol to show the viewers' relationship with the podcasts.

Would require a protocol and an API to do that. So, if have already given money to “this American life” and you are on Itunes, see the loop there on iTunes. Want to unpack what that symbol means. Would it make a call to a different window.

Would go to a rules engine.

Information cards and card selector model provide infrastructure.

What is under discussion now is selector based model. Would like to take that to Google and say here it is. This will help with customer service. Apple could be a payment mechanism as well.

Want to have option available to others that have not yet contributed.

Notion that all computer devices with be selector based because expedient. Selector smart enough to display only those that are needed at that time. Have multiple secure back channels controlled by user. That would be useful for VRM construction.

*Data set – could be a link
*Card
*Rule set

Does the R button indicate an action or a state? It is a state that supports an action

“states” are intention to buy, intention to sell, etc.
In this context

See – Information card.net for white paper. (cookie versus selector model)

Question of just speaking of existing business models. If combine VRM with social graph. VRM can combine social aspect with it. Response is that can do it now with infrastructure and buy in for entities.

This is a business model for musicians. Any musician that does this.

What if iTunes charged zero or a fixed price. Want to provide them with a kit to drop in to the existing application.

DMCA – left streaming unsolved. Record companies not like internet radio stations. No willing buyer and seller. Copyright arbitration royalty panel was fashioned. RIAA liked it, stations not like it. Public radio had a carve out. That ran out – copyright royalty board was fashioned. More high power. Still favored the RIAA. In absence of willing buyer/seller.
They set the pricing gun at X price per listener. Sound exchange get the money to the artists. What if a willing buyer system. Can listen to whatever you want, wouldn’t mind paying small amount per song. It is micro accounting – keep track of what listen to and work out what will pay over time. Accumulation of information on what have listened to enable payments.

This could play in the YouTube world also.

Take the standards, protocol and API and drop them in.

Value of Verified ID

2011-02-07T14:31:27Z

WikiSysop: Undo revision 3205 by Igiwydijok (Talk)

'''Conveners:''' Denise Tayleo, RL “Bob” Morgan

'''Attendees:'''
* Matt Klein
* Jeff Shan
* Marty Schleiff
* Jeff Stollman
* Kevin Trills
* Lucy Lynch
* David Brown
* Terry Hayes
+ dozen more

'''Technology Discussed/Considered:'''

Relying party and identity/claim provider relationships where data about subjects is “verified” rather than ? asserted.

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

“Verified” is probably too narrow a concept. The real differentiation for some claims/attributes is that they are claimed by the asserting party to be useful for or compliant with some defined business process. This might involve some defined verification method (or set of methods) but might also involve things like user consent, notification of others (eg parents), auditing etc… The state of the art is to bake notions of “verified” (etc…) into claim definitions or business agreements. An interesting subject is permission management (“can use feature X”). Defining authority is not always clear, ef for age. Large intersection with Level of Assurance concepts.

Adding “verified” or “complaint” decoration to each delivered claim is appealing but too complicated so far. Many of their issues were dealt with in PKI certificate policies 15 years ago, but this has seen little use, and even there proliferation of per-company policy attributes was a problem.

Verified Identity Claims

2011-02-07T14:27:05Z

WikiSysop:

'''Issue/Topic:''' VERIFIED IDENTITY CLAIMS – An introduction to U-Prove privacy-enhancing technology

'''Session:''' Tuesday 3C

'''Conference:''' [http://iiw.idcommons.net/Iiw11 IIW-11] November 2-4, Mountain View, [http://iiw.idcommons.net/Notes_IIW11 Complete Notes Page]

'''Convener:''' Craig Wittenberg (Microsoft)

'''Notes-taker(s):''' Ariel Gordon (Microsoft)

'''Tags:'''
Verified Claims; Identity Attributes; Privacy; Privacy Enhancing Technology; Cryptography; user-centric technology: user control.

'''Participants:'''

*Craig Wittenberg Microsoft
*Ariel Gordon Microsoft
*Jan Unger
*Tim Cole KuppingerCole
*Bret Tobey Assa Abloy
*John Fontana Ping Identity
*Jon Webb Sony PlayStation network
*Nishant Kaushix Oracle
*Takeshi Kitagawa NTT Communications
*Mark Horstmeier Kynetx
*Matt Tebo Proviti
*Greg Turner Sierra Systems
*Mike Min Booz
*Guibin Kony Google
*Aravmdan Ranga PayPal
*Tom Leon AOL
*Jim Fenton Cisco
*Dale Olds Novell
*Ben Goodman Novell
*Fady Semaan AOL
*Henrik Biering Peer Craft
*Stuart Proffitt Novell
*Jeff Stollman Secure Identity
*Ambarsh Malpar CA
*Alex Ran Intuit
*Thomas Hardjono MIT Kerberos
*Peter Capek Self
*Lloyd Burch Novell
*Kimberly Little LexisNexis
*Frank Travestino eBay
*Heather Ford UC Berkeley

'''Discussion notes:'''

[[File:U-Prove_technology_overview-Nov2010.pdf]]

Verified Identity Claims -- Technical introduction
Craig Wittenberg presented the U-Prove technology
U-Prove well respected in academia. Originally created by Credentica; purchased by Microsoft two years ago; incubated as part of the Verified Claims Team .

Similar characteristics as X.509 certificate but with much better privacy characteristics.

Craig presented a few scenarios, starting with Alice purchasing wine online and proving that she's over 21 and that she's a resident of WA state. Other scenarios included leveraging a German eID to access citizen and private services.

Many clarification Q&A followed on the technology and its benefits, including:

Q: Why not do back-end attribute exchange? Why go through all this trouble for exchanging attributes?

A: There are scenarios with privacy requirements such as un-traceability. If you take the case where Governments issue identity claims, there are requirements for the government not to be able to trace where the user is using his proof of age (for example). Depending on the geography, the privacy requirements may come from the government itself or from Privacy Groups.

Q: If there is a Cloud Service that stores and releases information, does it effectively create a secondary IdP?

A: If there are no client side bits, there is effectively a “broker” in the cloud that manages the user’s private keys. Microsoft and its partners are investigating different ways to build the u-prove verified claims agent that mitigates those issues.

''there is a powerpoint deck associated with this session: U-Prove technology overview-Nov2010.pptx''

User-Managed Identity Use-Case Gathering

2011-02-07T13:27:40Z

WikiSysop: Undo revision 3254 by Igiwydijok (Talk)

'''Conference [[Notes_iiw8|IIW8]] Room/Time:''' 5/?

'''Convener:''' J. Trent Adams (ISOC)

'''Notes-taker:''' J. Trent Adams (ISOC)

'''Attendees:'''

*Iain Hendersen (MyDex)
*Ariel McNichol (mEgo.com)
*Sarah Dopp (Cerado)
*Jens Haensser (UBC)
*Eve Maler (Sun)
*Alan Karp (HP Labs)
*Vittorio Bertocci (Microsoft)
*Asa Hardcastle (OpenLiberty)
*@Theron (PeoplePond)
*George Fletcher (AOL)

Technology Discussed/Considered:

We spent the time identifying and briefly discussing use cases for identity management around information access and sharing. The goal was to capture the use cases, to flesh them out later, then make them available for the community.

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Use Cases Gathered:

*Certification Management: Emergency Responders
*Authorized Service Chaining: Back-Up Services
*Delegated Resource Authorization: Attenuated Delegation
*Healthcare: Doctor Referral Process
*Change of Address: Battered Spouse Scenario
*Social Graph Access: Privacy Tuning by Policy
*End of Service Data Access: Service Shutdown / User Death
*Education Data Access: Parent/Payer of Student
*Social Network: Content Distribution Policies, Control, & Enforcement

High-Level Takeaways:

*Be careful when creating use cases not to incorrectly apply physical world comparisons to digital identity management; they don't always have a one-to-one analog. Identity management use cases often have multiple points of view (aka multiple first parties) with their own scenario variants.
*Delegated authority use cases need to clarify the chain of access controls required.
*Access policy variants need to be handled as scenarios within specific use cases, including exceptions (rather than trying to over-bake the use case to cover all possibilities).
*Use cases as patterns for scenario implementations should help re-set much of the discussion around what has been acceptable, and what should be improved in future solutions.
*Data access and transfer points within the use case need to be clearly called out so that they are addressed by user-managed control points.

Use Cases for Identity Brokers

2011-02-07T13:27:36Z

WikiSysop: Undo revision 3033 by Igiwydijok (Talk)

'''Conference [[Notes_iiw8|IIW8]] Room/Time:''' 12/G

'''Convener:''' Ben Sapiro/Ashish Jain

'''Notes-taker:''' Ben Sapiro

'''Attendees:''' Alan K, Bob P, Alavilli P, Vittorio B, Ray V, Ashish J

'''Technology Discussed/Considered:''' Identity Broker Uses Cases

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

IP needs to have some sort of accreditation

why would the RP pay?

Alcohol sellers online
*verification that you're a child by accessing a school database
*Red flag automation for

you do not have correct control of the data collection

An industry based IP -
*all the banks want to have one single phase
*all the attorneys have one single issue

you become a very attractive target if an attacker can get onboard and generate identities via you

the more datasources you aggregate, the more useful you are - but the more risk you will be faced with

not unlike OpenID OP vs IdP debate - but unless you actually issues Identities, you're just an Identity Owner (not a provider)

An IP can perform correlations across multiple data sources

This is done in federation. Example – citizen of EU --> Italian IdP (using on behalf-of)

the main value is providing access to the data, not in aggregation (that is clearly secondary)

some of these are claims, some of these are too close to be background checks
*Is sex offender
*is criminal
*education history
*employment history
*DOB/Age/Over18
*Address verification
*Credit Check
*valid insurance
*reputation
*driving record
*frequent flyer miles
*# of linkedin connections
*citizenship
*property ownership
*marital status
*connections to a group
*affiliations/membership
*professional status
*email ownership

(these have to be actively consumed by a third party, otherwise it's just information)

(if the information is about the requestor, it's a claim, otherwise not)

would require in-place access to data (no copies)

would require strong legal contracts forbiding mix and match to achieve information leakage

need to expose which sources you queried but not what the answers were

pricing could be comensurate with assurance level (did I ask gold level or silver level information sources)

pricing could be commensurate with granularity of information exposed (boolean versus scored)

Identity Broker is actually a claims broker (strict definition)

would need a process to feed in annotation/corrections and handle disputes

how do we resolve inconsistent data (database does A does not match B and C)?

Left Side of Board

Right Side of Board

Using the Relationship Layer to Create Trusted Age Credentials

2011-02-07T13:27:30Z

WikiSysop: Undo revision 3165 by Igiwydijok (Talk)

'''Convener:''' Kevin Trilli – Assert ID

'''Technology Discussed/Considered:'''

Converting a social network profile into a trusted identity/age credential by combining peer verification with social network analysis

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

* The proposal discussed how certain social network profiles can be converted to higher assurance identity credentials by leveraging the social graph as a peer verification method (“web of trust”.) However to enable universal applicability, the method is needed to quantify, in a standardized fashion, how trustworthy a credential is to a relying party. An algorithmic approach was proposed to score each asserted and verified attribute.

* Feedback included concern of mass collusion by kids all faking their ages, the purely online nature of the process, and direct involvement of ? consumers. (NOTE: the first two points are considered by the algorithm of the current approach)

* Other comments acknowledged it useful as a broad approach to creating verified identities where incentives to lie are not so high universally.

* Other suggestions included looking into easier attributes to verify initially that could provide a filter for the initial constituents & a foundation for specific attributes like age.

More detail can be found at assert ID.com, or by contacting jnchoi@stanford.edu

URL-Sharing Using the OExchange Protocol Stack

2011-02-07T13:26:53Z

WikiSysop: Undo revision 3234 by Igiwydijok (Talk)

'''Conference:''' [http://iiw.idcommons.net/Iiw10 IIW 10 ] May 17-19, 2009 this is the complete [http://iiw.idcommons.net/Notes_IIW10 Complete Set of Notes ]

'''Metadata'''

Issue/Topic: Sharing URLs with the OExchange Open Stack

Tuesday – Session 3 - G

Convener: Will Meyer

Notes-taker(s): Charlie Reverte

Tags for the session - technology discussed/ideas considered:

OExchange, XRD, XRDP, XAUTH, Host-Meta, Sharing, NASCAR

'''Notes'''

''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:''

trying to enable sharing to long tail services from content publishers. few goals, standardize way to send urls (exchange) to any site on the web, discover new services and allow users to personalize services that they see. services won't always be known at design time, use a late binding so new services can be discovered.

exchange: the service has an "offer" endpoint, standardize the params for passing an url, title, etc.

discovery: xrd document that describes the service, the name, "share" verb (send to, tweet this, translate). the service xrd is linked to from the site's host meta and via link tags in the page head (similar to rss).

personalization: publisher can offer you sharing options to the set of sites that you actually use including long tail sites they wouldn't normally link to. niche communities often have higher engagement and drive more traffic than general purpose social networks.

multiple options for persisting a user's service preferences, xauth, cookie, browser local storage, webfinger. webfinger is preferable as it persists across machines and allows others to discover services you use (and interact with you on those networks).

goals are to first codify how sharing is done today, later try to add options for new flows like popups, headless sharing, etc.

questions about splitting the personalization, personal discovery part into a separate spec; the exchange and service discovery parts are ready to go but webfinger etc aren't deployed yet.

there are roles for the browser here, to help discover new services and store preferences for services that you don't want to be public

'''Related Slides:'''

[[http://www.slideshare.net/willmeyer/iiw10-nascar-for-sharing Nascar for Sharing]]
[[http://www.slideshare.net/willmeyer/oexchange-technical-intro OExchange Technical Intro]]

User-Driven Search

2011-02-07T13:26:01Z

WikiSysop: Undo revision 3143 by Igiwydijok (Talk)

Diagram Venn:

Yours | Ours | Mine

Models to
# Turn Data Flow (PI) On/off
# Visible / Editable PI
# Selective Portability
* Privacy
* Access Rights

Use Case Selection and Metrics

2011-02-07T13:25:56Z

WikiSysop: Undo revision 3009 by Igiwydijok (Talk)

'''Conference [[Notes_iiw8|IIW8]] Room/Time:''' 9/A

'''Convener:''' Eve M and Alan K

'''Notes-taker:'''

'''Attendees:'''

'''Technology Discussed/Considered:'''

'''Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:'''

Alan presented an example from the physical world that demonstrates the following aspects of sharing that we should seek to emulate in the online world:

*Dynamic (no pre-setup to enable sharing)
*Chained
*Cross-domain
*Composable (merging rights and sharing from multiple sources)
*Attenuated (rights can be strictly subsetted as you go along)
*Accountable

He proposes selecting one or two use cases and explore them in depth to see if they have the characteristics we're all seeking.

We had a short discussion about how hard it is to separate metrics for use cases from metrics for solutions to the use cases.

Eve proposes that we need dynamicism of this sort: A user can choose to publish a URL that a potential data recipient can attempt to retrieve against, where the recipient didn't have to take any steps prior to the initial GET attempt and where the attempt doesn't necessarily result in a successful retrieval.

Peter Davis proposes a specific use case involving wanting to share an album of event (e.g. camping) photos, the subjects of which are minor children, with exactly the set of dads whose kids are in the pictures, without exposing the pictures to anyone else. Trent proposes a variant where the photographer is a professional who has to get signed release forms, such that the list of people with whom you want to show the photos is known. For someone to print a photo, you need to share the photo with them.

Many services do photo sharing today by emailing special URLs to give people (who are not otherwise known to the photo service) to get access to the data.

Eve proposes that a use case metric we should adopt is that keeping the URL secret should not be relied on for the security of the overall system. We started calling this a "suckiness" factor. :-) Peter is going to have to solve this for his camping photos by explicitly constructing a photo-sharing Facebook group for this event that names the people explicitly! Alan then proposes ease-of-permissioning as a solution metric -- "pain-in-the-assiness". :-)

Bill Smith had described the enterprise outsourcing use case on Monday; some companies, especially really small ones, often outsource everything. Peter elaborates: five guys get into a room and declare they're part of a company. Now you have to control access to all sorts of resources (sharing documents, authorizing bill payments, etc.).

Peter describes an enterprise use case where the entire company collaboratively serves in a policy-making function. Any employee can contribute a product idea, and if a really good one arises, people can decide that it needs to be subsequently restricted from the view of the entire company, to protect it.

Asa described managing entreprenurial discussions with reputation systems (a discussion that took place at the Berkman Center).

The separation of policy decision-making and policy enforcement is important.

There's a database that relies on trusted experts to indicate who is the author of a book, the heir of an author, etc. An author might want to have an agent operating on their behalf asserting the author's rights in the work. The trusted experts perform, in effect, identity proofing.

Revocation of various sorts came up. Peter may want to deprovision the rights of a particular person to access photos, including destroying their cache of photos! And Alan points out that if Wikipedia wants to revoke a "bad" editor's rights, it also might want to roll back any content the person had contributed.

10:15am hour:

We walked through the photo-sharing use case in detail:

Assumptions:

*There is at least one parent on the camping trip who doesn't want photos of their kids put online.

*The person who took the photos can always view photos of their own kid.

*The online photos in question are referenceable individually and in a collection.

*People who want to use a photo you took need to seek your permission to use it, print it, etc.

1. Peter goes on a camping trip, taking photos as he goes.

2. He meets or knows most, but not all, of the other participants in the trip. And some situations involve total strangers (others at the swimming hole that day). Photojournalists takes pictures and then immediately seeks releases.

3. He returns home and publishes a set of photos from the trip, initially to himself.

4. He shares access to the photos with a selection of people, including the parents of the photo subjects, who can then themselves share access to selections of other people.

5. One of the other parents, who had taken their own photos during the trip, wants to add those photos to the set, with all the data-sharing properties you have set up for the photo set as a whole.

6. Grandma, with whom two different parents (her son, Peter, and her daughter) have shared separate photos of their kids, wants to "mash up" the photos into a composite such as an online scrapbook page.

7. Grandma wants to share her scrapbook page, which contains two different photos that have different data-sharing rules attached to them, with her bridge club.

8. One of the other parents is a professional photographer and takes advantage of his Creative Commons copyright license grant to create derivative works to crop and edit the photo. Later, when his kid leaves the troop, you want to revoke his rights to the photo set.

Alternative scenario: Grandma doesn't do stuff online, but subscribes to a service that prints and sends her photos. Peter wants to give printing/sending access rights to the service. (This gets at the VRM individual-to-service data-sharing use cases.)

Having built the use case and its variant, we discussed what metrics any solutions could be measured on. Here's a composite list of the ones we've discussed to date:

*Dynamic (no pre-setup to enable sharing)
*Chained
*Cross-domain
*Composable (merging rights and sharing from multiple sources)
*Attenuated (rights can be strictly subsetted as you go along)
*Accountable
*Usable
*"Security" (practical ability to control access to the desired people)
*The "oops factor" (when security can be accidentally compromised even by sophisticated users -- related to security+usability)

There's a bunch more, largely obvious, that we didn't have time to list.

We discussed reserving the word "suckiness" for the ability (actually the lack thereof) of a particular solution to meet a metric, rather than one of the metrics itself. :-)

Alan suggests that URLs should be used as rights-carrrying objects; several others objected because URLs were designed precisely to "give directions" for where to get a resource.

We ran out of time to review various existing and proposed solutions against the various metrics. This is an exercise that can be done offline (perhaps on the community@lists.idcommons.net list?).

Using DNS ENUM

2011-02-07T13:25:53Z

WikiSysop: Undo revision 3347 by Igiwydijok (Talk)

User Managed Access - UMA

2011-02-07T13:25:48Z

WikiSysop: Undo revision 3356 by Igiwydijok (Talk)

Issue/Topic: User-Managed Access (UMA)

Monday – Session 3 - E

Convener: Eve Maler

Notes-taker(s): Tom Holodnik

'''Tags:''' #UMA #authorization #user-centric #OAuth #JSON #Python #policy #claims

'''Discussion Notes:'''

For complete details, please see: http://kantarainitiative.org/confluence/display/uma/Home

The protocol flow is described here: http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol

Here’s a friendly overview: http://kantarainitiative.org/confluence/display/uma/UMA+Explained

Session slides: http://kantarainitiative.org/confluence/download/attachments/37751312/IIW10-UMA-May2010.pdf

History:

ProtectServe evolved into UMA.
Last IIW, WRAP was presented; it overturned some OAuth dependencies that UMA had had.

UMA:

Influences:

* policy-decision making
* privacy
* informational self-determination
* data portability
* the "open stack"
* volunteered personal information
* personal data stores

outcomes:

* a dashboard that allows you to control access
* engaged data sharing

* a protocol headed toward IETF applications area
* a set of draft specs free for anyone to implement
* multiple implementations under way
* simple, OAuth-based, identifier agnostic, RESTful, modular, generative (can be used to build more things) and developed rapdily
* targeting delivery as a spec (to IETF) in the August time frame

The players:

* Authorizing user - a web user who config's the AM with policies to control how to make access control decisions)
* Host (protected resource server) - enforces access to the protected resources it hosts
* Authorization Manager (AM) - carries out an authorizing users policies
* Requester - an entity that wants to access the AU's resources

Compare OAuth and UMA models:

* the UMA model is different from the OAuth model in subtle ways; it establishes a contract for access management
* the UMA AM may also usefully be co-located with IdP and discovery

participants:

* there is one resource owner and consumer in OAuth; the UMA user may be granting access to an autonomous party
* resource server respects tokens from its authz server; the host outsources authz jobs to an authz manager chosen by the user
* the authz server issues tokens based on the client's ability to authN; the authZ manager ussues tokens based on user policy and clienams coneryned by the requester

provisioning:

* client and server must meet outside the OAuth context to provision trust; the requester can walk up to a protected reseource and attempt to get access without registering first

dynamic trust:

* the resource server meets its authz server ahead of time and is coupled with it; the authz user can mediate the introduction of each of the hosts to the authz manager we wants to use
* the resource server validates tokens in an unspecified manner, assumed locally; the host has the option to ask the authZ manager to validate tokens in real time

protocol:

* OAuth: get a token, use a token; uma: intro, get token, use token
* user delegation flows and automous flows; UMA: profiles of OAuth flows

relationship with OAuth: based on OAuth 2.

UMA Protocol Details: (reference the links at the top of the notes)

Establishing trust; passing a handle to the protected resources

* could establish trust on first use (TOFU)

Policies:

* unilateral - e.g. allow access for a week
* claims-requiring - "allow anyone access who agrees to my licensing terms" or allow access to someone who can prove themselves to to bob@mailco.com, or allow access to anyone 18 years old or more.

Claims 2.0 are by default JSON based claims that establish attributes about a user; they don't have to be issued by the requester, but they could be issued by an IdP associated with the requester.

Demos and Implementations in progress:

SMART at Newcastle University: This illustrates how to issue and manage simple kinds of claims:
http://kantarainitiative.org/confluence/download/attachments/38371737/SMARTOverview.pdf
http://kantarainitiative.org/confluence/display/uma/SMART+project+user+experience

Christian Scholz: This illustrates how we might create policies and provision access to resources we want to protect with an UMA AM:
Prototype: http://bitbucket.org/mrtopf/uma
Demo: http://host.clprojects.net/

Comment: if the token does not contain information about the resource (and to whom it was issued), it's vulnerable to confused deputy

claims confirmation could be as simple as "confirm that you are over 18" or "confirm that you will abide by the terms of Creative Commons..." - enforceable legally, or could be supported by claims issued through CardSpace/InfoCards, could be a URL of a BBB statement, or a URL pointing to other indepedent assertion of claims.