Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Jan 29-31 Provo F2F Agenda"

(→‎9:30 [1+hr] IdAS & IGF Design [Jim and Phil])
(→‎9:30 [2:20 hrs] IdAS & IGF Design [Jim and Phil])
Line 55: Line 55:
  
 
=== 9:30 [2:20 hrs] IdAS & IGF Design [Jim and Phil] ===
 
=== 9:30 [2:20 hrs] IdAS & IGF Design [Jim and Phil] ===
−
* [1hr] [Phil Hunt] Presentation of IGF Requirements
+
Session Notes
−
* [1:15] Discussion
+
 
−
** Capture resulting IdAS requirements here:
+
First, Jim referenced previous materials at [http://wiki.eclipse.org/Identity_Attribute_Service Identity Attribute Service page].
 +
 
 +
All of this material is either publicly released or released under the Apache license of the OpenLiberty Project.
 +
 
 +
Mary clarified that this conversation is about the potential support that Higgins may provide for the IGF. Tony felt it was important that we not discuss any potential changes to the IGF work.
 +
 
 +
Phil clarified that the IGF specs have not been finalized.
 +
 
 +
Phil walked us through the IGF background presentation (sent by Jim to the list):
 +
* Two track approach
 +
** Development of open source components at www.openliberty.org
 +
** Technical work – specs and profiles – ongoing at Liberty Alliance TEG
 +
 
 +
IGF is currently a set of declarative contracts that document and govern exchange of identity-related data between consumers and providers.
 +
* Attribute authorities using policies describing their acceptable use
 +
* Requesters have the corresponding requirements for describing their needs
 +
 
 +
App developers are not identity experts. IGF lets them do:
 +
* High-level expression of identity req’s
 +
* Ability to use both silo’d and standardized schemas
 +
* Tools and frameworks for developers are key
 +
 
 +
Deployers
 +
* Need ability to understand schema and transactions in advance
 +
* Must support Privacy Impact Assessment
 +
* Ability to map client req’s to identified authorities
 +
* Ability to apply deployment declarations and req’s
 +
 
 +
Users
 +
* Capture what agreements the user accepted
 +
* Reflect consent and purpose of data use
 +
* But IGF does not directly address interactions with users
 +
 
 +
Attribute Authorities
 +
 
 +
Proposed Standards Components
 +
* CARML – Defines application identity req’s
 +
* WS-Policy Support – Compile time & deployment time assertions & declarations
 +
* AAPML – Defines identity usage policies (XACML)
 +
* Attribute Service
 +
 
 +
CARML
 +
* Schema
 +
** Attributes
 +
** Predicates
 +
** Roles
 +
** Filters
 +
 
 +
* Interactions
 +
** Authenticate
 +
** Search
 +
** Read
 +
** Add
 +
** Modify
 +
** Delete
 +
 
 +
Similar to WS-Policy – will result in suggested changes/enhancements
 +
 
 +
WS-Policy Assertions
 +
* Compile time policy
 +
* Deployment time policy
 +
 
 +
Transaction Metadata
 +
* Not protocol specific
 +
* 4 Request Assertions
 +
* Response Assertions
 +
 
 +
Assurance, Governance, and Run-Time Protocols
 +
 
 +
How does this tie into Higgins?
 +
 
 +
Phil is building an Attribute Services API which fits over IDAS. An application can register with the “stack” and register its own credential, and then provide the user’s credential, then ask for the attributes it needs.
 +
 
 +
IGF’s goal is to get this layer implemented in all major IDEs. Eclipse would be first, but NetBeans, .NET, others would follow.
 +
 
 +
Contact info for Phil is at the end of the slides.
 +
----
 +
Jim followed and said that the IGF work brings up the following points:
 +
 
 +
* IDAS API extensibility
 +
* Higher level abstractions, i.e., an app wants an attribute and doesn’t have context-specific knowledge.
 +
 
 +
We discussed the latter a little. Paul explained that the context metadata available for configuration has a link to the context schema, so that data could be discoverable. Mike pointed out that in many cases, the requester needs to authenticate before they can access the context description. Also, within enterprises, the contexts are well known.
 +
 
 +
Phil was saying that even in enterprise contexts, automated discovery can be very helpful.
 +
 
 +
Dale asked how this was like UDDI. Phil said that with IGF, the app is declaring what it needs, and the infrastructure is figuring out how to provide it. The goal is for the app to be able to describe what it needs. That’s the opposite of what UDDI does, which is the app doing active discovery.
 +
 
 +
This led to a long discussion about context description and discovery of context capabilities.
 +
 
 +
Prateek said that the purpose of the IGF is not to require an identifier to bind to a repository (as Higgins Global Graph requires), but to deal this as at a business layer, using policy declarations.
 +
 
 +
Jim drew a picture of treating IDAS itself as a context provider (CP), and then an app can talk to THAT CP and ask it at a higher layer – such as the policy level – and then this IDAS CP as an “aggregated context provider” can talk to other CPs to discover and provide that information. An IDAS CP could take care of:
 +
* mapping
 +
* policy resolution
 +
* conflict resolution
 +
 
 +
There was discussion of the difference between runtime and deploy time application of policy fulfillment.
 +
 
 +
Mike drew the distinction between:
 +
# I know Paul’s name and I need to find a CP that can give me his birthdate.
 +
# I want to know if Paul is an adult.
 +
 
 +
Phil pointed out that from a privacy perspective, it’s better for an app to ask, “Is Paul an adult” than “Give me Paul’s birthdate”.
 +
 
 +
Phil also explained that what the higher layer would provide is a way to ask the question, “Here is Paul’s identifier – I need the following three attributes for the following purposes” and let the higher-level interface figure out which CPs can do this.
 +
 
 +
Paul explained further about the [http://wiki.eclipse.org/Higgins_Global_Graph “Higgins Global Graph”].
 +
 
 +
Tony said his issue with IGF is that discovery of CARML and AAPML is that it reveals too much info and thus has serious privacy implications. Phil explained that CARML and AAPML is designed for deployment time setup that reflects pre-existing business relationships, and makes those available for enterprise apps to understand and deploy against. It is not designed for “at a distance” relationships and dynamic trust networks such as OpenID.
 +
 
 +
Phil again provided the example that one CP may have a schema that exposes “isAdult” whereas another may only have “birthdate”, and the purpose of the layer he’s discussing would be able to deal with those differences.
 +
 
 +
It was agreed that what Phil would like to do happens at a layer above the [http://wiki.eclipse.org/Higgins_Global_Graph Higgins Global Graph]. At a minimum you would be able to discover not just the data model of a context, but the policies under which it is willing to release attributes.
 +
 
 +
Phil clarified: the app developer says, “This is what I need”. The deployer may add to that, “This is the assurance I need.” Then the question is, how do you implement this?
 +
 
 +
Prateek says that you could send a CARML document to a service and receive another CARML document back, i.e., the first says, “Can you do this for me?” and the answer is, “Here’s what I can do for you?”
 +
 
 +
Tony explained that today, the app gives its WS-Policy to the IdP, and the IdP figures out the CPs to talk to fulfill it.
 +
 
 +
Phil explained that the problem is, “How does the app configure itself to get its needs fulfilled?” If the developer can just right CARML and give it to a service, that’s the goal.
 +
 
 +
Paul drew a picture of a WS-Policy request coming into an STS. The STS would then query IDAS for the attributes it needs to fulfill the policy.
 +
 
 +
Phil pointed out that from the perspective of an app, the STS is a service. So the STS is really what has an AAPML policy and could accept CARML requests. Phil suggested it could then recurse one level lower, i.e., the STS could send CARML to CPs, and CPs could publish AAPML.
 +
 
 +
This led to a discussion about the relationship of policy to STSes and Higgins CPs. Mike thought that Higgins has a way to query each CP for metadata. That metadata could include the WS-Policy that applies to that context.
 +
 
 +
Jim checked and Higgins doesn’t currently have metadata on a context. However we could add it.
 +
 
 +
Mike said that yes, we could do that, but the issue is really what will be done with that kind of metadata, and how we will achieve it.
 +
 
 +
Tony said that the approach was do define “dialects” which define which bucket of metadata you extract. The three dialects were WS-Policy, WSDL, and XACML.
 +
 
 +
Mike suggested that we have “pluggable” policy providers.
 +
 
 +
Paul drew a diagram showing how a context could expose metadata about the policies. Mike favored the idea that a CP could provide metadata to an STS, so that an STS can get the metadata it needs from a source.
 +
 
 +
Paul concluded that we can store CP-related policy (such as WS-Policy) as metadata on a context without changing the IDAS API.
 +
 
 +
Next, the conversation moved to the question of delegation and how its currently handled by the IDAS interface. The issue of "app X is making this request on behalf of user Y". No conclusion was reached.
 +
 
 +
Jim asked the question, "Do we want to address API extensibility in 1.0 or not?" If not, we can put this off.
 +
 
 +
Mike noted the different levels of APIs that Higgins describes:
 +
* Experimental
 +
* Provisional <-- Mike favors this one
 +
* Platform
  
 
=== --> 11:50 [15min] Higgins 1.0 Release Plans [Mary] ===
 
=== --> 11:50 [15min] Higgins 1.0 Release Plans [Mary] ===

Revision as of 14:59, 29 January 2008

Higgins face-to-face meeting in Provo, Utah, January 29-31, 2008.

Contents

Logistics

  • Location: Executive Briefing Room 1, Building H, Novell's office. 1800 South Novell Place, Provo, UT 84606, (801) 861-7000, map
    • After you enter building H, the executive briefing rooms are through glass doors on your right.
    • Call Jim at 801 380 8760 if you have any problems.
  • Time: The event will start Tuesday at 9:00 AM and end Thursday at noon.
    • A continental breakfast will be available starting at 8:30 AM
    • For early-comers and late-leavers, we're planning one or more ski days. See the ski poll
  • Hotel: Several of us are staying at the Marriott Conference Center in Provo (Map). There are also a few hotels within walking distance (may have to deal with snow though)
  • Weather: Dress warmly. It may be cold.
  • Getting there: Most people fly into the SLC airport and drive to Provo. Here are directions from SLC International Airport to Novell.

Expected Attendees

  1. Dale Olds - Novell
  2. Jim Sermersheim - Novell
  3. Mary Ruddy - SocialPhysics/Parity
  4. Paul Trevithick - SocialPhysics/Parity
  5. Tony Nadalin - Bandit
  6. Tom Doman - Novell
  7. Daniel Sanders - Novell
  8. Phil Hunt - Oracle
  9. Drummond Reed - Cordance/Parity
  10. Andy Hodgkinson - Novell
  11. Duane Buss
  12. Michael McIntosh - IBM
  13. Markus Sabadello - Parity
  14. Carl Binding - IBM
  15. Uppili Srinivasan - Oracle
  16. George Stanchev - Serena
  17. Anthony Bussani - IBM

Attending by Phone (888-457-5984, passcode 5849826). Alert us on #higgins IRC for agenda items you wish to join for:

  1. Brian Carroll - Serena
  2. Paula Austel - IBM
  3. David Primmer - Google (for session on STS IdP + SAML IdP refactoring)
  4. Bruce Rich - IBM
  5. Greg Byrd - IBM (for configuration discussion, possibly more)

Tuesday

NOTES ON THE AGENDA PROCESS

The agenda as proposed on this wiki page is just a place to start. Usually we rearrange and adjust the topics as the meeting progresses. We take notes right in this wiki page. If a demo is included it is in the topic's title line "[DEMO]". If the topic can't be moved there should be a bullet.

We will track at least the agenda on the #Higgins IRC channel. If you wish to call in for an agenda item, please let us know on the #higgins IRC channel and we'll set up a conference bridge. The conference bridge number will be 888-457-5984, passcode 5849826

9:00-9:20 Welcome, Introductions, Logistics [Jim, Paul, Mary, (Dale)]

  • Introductions
  • Eclipse ground rules
  • Logistics
    • We will post the current agenda item to #higgins
      • Need IRC Scribes: Mike and Jim volunteered
    • Will take notes onto this Wiki
      • Need Wiki Scribes (we'll decide per session)

9:30 [2:20 hrs] IdAS & IGF Design [Jim and Phil]

Session Notes

First, Jim referenced previous materials at Identity Attribute Service page.

All of this material is either publicly released or released under the Apache license of the OpenLiberty Project.

Mary clarified that this conversation is about the potential support that Higgins may provide for the IGF. Tony felt it was important that we not discuss any potential changes to the IGF work.

Phil clarified that the IGF specs have not been finalized.

Phil walked us through the IGF background presentation (sent by Jim to the list):

  • Two track approach
    • Development of open source components at www.openliberty.org
    • Technical work – specs and profiles – ongoing at Liberty Alliance TEG

IGF is currently a set of declarative contracts that document and govern exchange of identity-related data between consumers and providers.

  • Attribute authorities using policies describing their acceptable use
  • Requesters have the corresponding requirements for describing their needs

App developers are not identity experts. IGF lets them do:

  • High-level expression of identity req’s
  • Ability to use both silo’d and standardized schemas
  • Tools and frameworks for developers are key

Deployers

  • Need ability to understand schema and transactions in advance
  • Must support Privacy Impact Assessment
  • Ability to map client req’s to identified authorities
  • Ability to apply deployment declarations and req’s

Users

  • Capture what agreements the user accepted
  • Reflect consent and purpose of data use
  • But IGF does not directly address interactions with users

Attribute Authorities

Proposed Standards Components

  • CARML – Defines application identity req’s
  • WS-Policy Support – Compile time & deployment time assertions & declarations
  • AAPML – Defines identity usage policies (XACML)
  • Attribute Service

CARML

  • Schema
    • Attributes
    • Predicates
    • Roles
    • Filters
  • Interactions
    • Authenticate
    • Search
    • Read
    • Add
    • Modify
    • Delete

Similar to WS-Policy – will result in suggested changes/enhancements

WS-Policy Assertions

  • Compile time policy
  • Deployment time policy

Transaction Metadata

  • Not protocol specific
  • 4 Request Assertions
  • Response Assertions

Assurance, Governance, and Run-Time Protocols

How does this tie into Higgins?

Phil is building an Attribute Services API which fits over IDAS. An application can register with the “stack” and register its own credential, and then provide the user’s credential, then ask for the attributes it needs.

IGF’s goal is to get this layer implemented in all major IDEs. Eclipse would be first, but NetBeans, .NET, others would follow.

Contact info for Phil is at the end of the slides.

Jim followed and said that the IGF work brings up the following points:

  • IDAS API extensibility
  • Higher level abstractions, i.e., an app wants an attribute and doesn’t have context-specific knowledge.

We discussed the latter a little. Paul explained that the context metadata available for configuration has a link to the context schema, so that data could be discoverable. Mike pointed out that in many cases, the requester needs to authenticate before they can access the context description. Also, within enterprises, the contexts are well known.

Phil was saying that even in enterprise contexts, automated discovery can be very helpful.

Dale asked how this was like UDDI. Phil said that with IGF, the app is declaring what it needs, and the infrastructure is figuring out how to provide it. The goal is for the app to be able to describe what it needs. That’s the opposite of what UDDI does, which is the app doing active discovery.

This led to a long discussion about context description and discovery of context capabilities.

Prateek said that the purpose of the IGF is not to require an identifier to bind to a repository (as Higgins Global Graph requires), but to deal this as at a business layer, using policy declarations.

Jim drew a picture of treating IDAS itself as a context provider (CP), and then an app can talk to THAT CP and ask it at a higher layer – such as the policy level – and then this IDAS CP as an “aggregated context provider” can talk to other CPs to discover and provide that information. An IDAS CP could take care of:

  • mapping
  • policy resolution
  • conflict resolution

There was discussion of the difference between runtime and deploy time application of policy fulfillment.

Mike drew the distinction between:

  1. I know Paul’s name and I need to find a CP that can give me his birthdate.
  2. I want to know if Paul is an adult.

Phil pointed out that from a privacy perspective, it’s better for an app to ask, “Is Paul an adult” than “Give me Paul’s birthdate”.

Phil also explained that what the higher layer would provide is a way to ask the question, “Here is Paul’s identifier – I need the following three attributes for the following purposes” and let the higher-level interface figure out which CPs can do this.

Paul explained further about the “Higgins Global Graph”.

Tony said his issue with IGF is that discovery of CARML and AAPML is that it reveals too much info and thus has serious privacy implications. Phil explained that CARML and AAPML is designed for deployment time setup that reflects pre-existing business relationships, and makes those available for enterprise apps to understand and deploy against. It is not designed for “at a distance” relationships and dynamic trust networks such as OpenID.

Phil again provided the example that one CP may have a schema that exposes “isAdult” whereas another may only have “birthdate”, and the purpose of the layer he’s discussing would be able to deal with those differences.

It was agreed that what Phil would like to do happens at a layer above the Higgins Global Graph. At a minimum you would be able to discover not just the data model of a context, but the policies under which it is willing to release attributes.

Phil clarified: the app developer says, “This is what I need”. The deployer may add to that, “This is the assurance I need.” Then the question is, how do you implement this?

Prateek says that you could send a CARML document to a service and receive another CARML document back, i.e., the first says, “Can you do this for me?” and the answer is, “Here’s what I can do for you?”

Tony explained that today, the app gives its WS-Policy to the IdP, and the IdP figures out the CPs to talk to fulfill it.

Phil explained that the problem is, “How does the app configure itself to get its needs fulfilled?” If the developer can just right CARML and give it to a service, that’s the goal.

Paul drew a picture of a WS-Policy request coming into an STS. The STS would then query IDAS for the attributes it needs to fulfill the policy.

Phil pointed out that from the perspective of an app, the STS is a service. So the STS is really what has an AAPML policy and could accept CARML requests. Phil suggested it could then recurse one level lower, i.e., the STS could send CARML to CPs, and CPs could publish AAPML.

This led to a discussion about the relationship of policy to STSes and Higgins CPs. Mike thought that Higgins has a way to query each CP for metadata. That metadata could include the WS-Policy that applies to that context.

Jim checked and Higgins doesn’t currently have metadata on a context. However we could add it.

Mike said that yes, we could do that, but the issue is really what will be done with that kind of metadata, and how we will achieve it.

Tony said that the approach was do define “dialects” which define which bucket of metadata you extract. The three dialects were WS-Policy, WSDL, and XACML.

Mike suggested that we have “pluggable” policy providers.

Paul drew a diagram showing how a context could expose metadata about the policies. Mike favored the idea that a CP could provide metadata to an STS, so that an STS can get the metadata it needs from a source.

Paul concluded that we can store CP-related policy (such as WS-Policy) as metadata on a context without changing the IDAS API.

Next, the conversation moved to the question of delegation and how its currently handled by the IDAS interface. The issue of "app X is making this request on behalf of user Y". No conclusion was reached.

Jim asked the question, "Do we want to address API extensibility in 1.0 or not?" If not, we can put this off.

Mike noted the different levels of APIs that Higgins describes:

  • Experimental
  • Provisional <-- Mike favors this one
  • Platform

--> 11:50 [15min] Higgins 1.0 Release Plans [Mary]

  • Review of 1.0 bug list
  • Status of IP Review – IP Log accepted
  • Status of Release Review
    • Have OK to hold review
    • Tentatively scheduled for Feb 13
    • First drafts slides due 1/30
    • Final slides due 1/3
    • Final slides posted by EMO on 1/6
    • Can release if get OK at release review (no more waiting period)
    • Possible Eclipse announcement date – Feb 20
  • Status of "graduation from incubation" review - Revisit this after complete Release Review and 1.1 planning
  • Eclipse Quality page

Lunch

Tuesday Afternoon

[1hr] API Extensibility [Jim]

[1hr] IdAS and the Higgins Data Model; Open Issues [Jim]

[10min] HOWL and the Higgins Data Model; Proposed update [Paul]

[30min] Higgins on Android [Tony, Paul]

  • IBM
    • IBM's CES Demo
  • Parity
    • [5min] Parity's work
      • WebKit limitations
      • Javascript injection approach
      • Challenges/Issues
      • Wishlist
  • Starting an Android work area within Higgins?
    • IP issues around Android
    • Contributions

[10min] DEMO: Eclipse-based Selector [Mike]

[45min+] Higgins Selector Selector [Mike, Paul]

[15min] Report on Java Impl Selector Performance Issues [Paul]

[45min] Selector UIs [Tony?, Andy?]

  • Higgins is blessed(!) with multiple i-card selector UIs:
    • client-based "DigitalMe" on Linux
    • client-based "DigitalMe" on OSX
    • Eclipse-based
    • web-based Firefox(in-browser)
    • web-based IE/AIR
  • Need to reduce the number of parallel implementations
  • Need to converge on a common UI
    • Document the steps in any login process where: (trying for "common enough" here)
      • The user needs to make a decision (e.g. to operate a control)
      • What information is needed by the user to make the decision
      • Where this information comes from
      • What is at risk if such a choice is hidden from the user, e.g. by user preference
  • Need to improve the UI
  • What about http://wiki.eclipse.org/User_Interface_Best_Practices_Working_Group

[30min] DEMO: Client-based Selector "DigitalMe" [Andy]

  • Demo
  • Current status
  • Integration of next-gen HBX and Higgins Selector Selector ??
  • Documentation
    • Harmonization of Bandit site
  • Roadmap

The Future of the Configuration Component

  • Configuration component: need two versions of Configuration.common (one for plugin-based configurations and one for jar-based configurations)
  • support "writing" not just reading
  • better support for passwords in the file
  • make it possible to do "round tripping" somehow (MikeM)
  • central configuration service?
    • problems: how to transfer stuff from file system (e.g. keystore) to the service?
    • we're currently passing objects around that are hard to serialize
    • use JSON
  • Configuration UI?
  • NOTE: Greg B. would like to call in, if this discussion happens. Any time other than 1-3:30pm Tuesday (Mountain Time) would be ok.

Autobuilds, Auto-tests

  • Eclipse features?
  • C++
  • Nightly Junit tests?

Moving, Renaming Components

  • Split selector selector from HBXIE
  • Plugins folder
  • .deployment.idas.basic -> move to app?
  • .rpps -> ss
  • .rsse -> rename to .ss.rsse

Access Control [Tom]

  • Access Control Issues in LDAP
  • Acesss Control Issues in JNDI
  • General Access Control Issues
  • Providing Access Control through IdAS

Wednesday

[2hrs] STS IdP Solution in Depth [Mike]

  • Similar to New York F2F sesion, but shorter
  • (Weds or Thurs please)
  • STS Work items:
    • STS token service still bypasses IdAS to access/update attributes
    • Sample STS should cut over to using XMLFile Context Provider
    • Use of "informationCard generator" in STS's profile service?
    • Currently the STS MEX endpoint only advertises support for transport-level security (using UN token or self-seigned SAML token)

[15 min] Card-based Oauth [Paul]

  • Support for Oauth in the world of Higgins
  • Oauth uses redirects all over the place and asks the person to sign in using un/pw at the service provider. There must be a better user experience.
  • How about O-cards? User experience:
    • User gets an O-card from Service Provider (e.g. Google Calendar)
    • User fires up Oauth Consumer that wants Google Calendar data stream
    • Selector appears with Google Calendar card displayed
    • Selector UI asks to approve grant of rights
    • User clicks "Approve" button
    • Done. [No redirects, no un/pw entry at SP, etc.]

[20 min] Considerations for a multi-protocol ID provider [Uppili]

  • When considering merging of STS and SAML from a Higgins infrastructure perspective, it will be useful to discuss and get some common understanding about what is the ultimate "functional" objective. Are there cross-functional use cases in scope for the resulting multi-protocol system, or are we just sharing code between what would be completely independent systems. Would this guide how to approach the same issue if a reference implementation of OpenID were considered as part of Higgins (in future).
    • Look at the canonical layers of an IDP
    • Allude about infrastructure building blocks that can be shared
    • Meditate about some cross-protocol use cases / scenarios (like global sign-out)
  • ( I think this item should be here or somewhere prior to the "Merging" discussion, below).

[45min] Merging SAML2 IdP into STS framework [Mike, Markus]

  • Pre-merge refactoring
    • Should we rename low level reusable sts.* components -> htp.* (Higgins Token Processing)
  • Task planning
  • Resources

[45min] [DEMO] Novell open source IdP presentation [Daniel]

  • (Weds or Thurs please)
  • This uses the Higgins STS and IdAS components. Presentation will include the following:
  • High level architectural overview of IdP and how Higgins STS and IdAS are used.
  • Demonstration.
    • Download the IdP tarball.
    • Build it.
    • Deploy to server that has Tomcat installed.
    • Configure using web based admin.
      • Miscellaneous configuration.
      • Configuration of attributes that can be stored.
      • Configuration of information card templates.
      • Configuration of Java keystore
      • Configuration of IdAS context provider.
      • Look at the XML configuration files that are generated by admin.
      • Customizing how the IdP will look and feel.
    • Create user account
    • Manage user account, including change password
    • Issue information card using a card template
    • Use information card

[10min] [DEMO] Web-based Selector Demo [Paul]

  • We've added what we think is a UI improvment over CardSpace UX: "remember this card (at this site)" (coupled with "remember this password for the card")
  • <Brian: I need wiki page describing logic if/else of this function>
  • Need to discuss "twinkle" idea, "unremember" function

[15 min] [DEMO] Web-based Selector Demo [Jeesmon]

  • [3 min] HBX/Firefox Demo [Paul]
  • [12 min] HBX/IE AIR web-based Selector Demo [Jeesmon remote from Needham, MA]
  • Architecture Diagram including integration with Selector Selector
  • Installation demonstration
  • Login to RP site demonstration

[20min] Separating out the Selector Authentication Service [Drummond, Paul]

  • Today the web-based selector uses a username and "master" password to authenticate directly to the back end selector service (aka rpps)
  • A new approach is to factor out provisioning and authentication of the client-side identity selector to separate web services. This approach has several advantages:
    • It can provide non-identifying tokens to provision and/or authenticate a back end selector service account, preserving privacy.
    • It can standardize provisioning and configuration of multiple front-end identity selectors (e.g., on different devices all used by the same user) to talk to the same back end identity agent.
    • It can opening new models of authentication in the future without requiring changes to the back end identity agent service.
  • Work has begun on a protocol for this purpose: ISAP - Identity Selector Authentication Protocol.
  • It lays the foundation for a "grand unification" of OpenID and Cards --The Selector Authentication Service can also (optionally) be the user's OpenID OP. We can nestle the concept of I-Cards UNDERNEATH the user's OpenID. OpenID's are great for public identification (e.g. log on to blogs, etc.) and for social networking and other low transaction value, public interactions where the person wants to use (or doesn't mind using) a 100% correlatable identifier. Cards are multiple, contextualized, nuanced and may be anonymous, pseudonymous, or partly to fully identifying. The opportunity here is to unify the two. Since the user already has an OpenID password at a service she trusts, we can (thanks to OpenID 1.1 and especially 2.0's XRDS discovery mechanism) simply add the Selector Service as a new XRDS service endpoint. The user now has only ONE master password. They have an OpenID that works anywhere and they have a card/selector service that integrates nicely with it. [Paul and Drummond are working on a white paper that describes this grand unification. The OpenID foundation is also exploring unification approaches, so this is all very timely]
  • We have begun conversations with OpenID providers on implementing ISAP on their end to allow them to offer selector services

[45min] Introduction to R-Cards [Paul]

  • Evolution of i-card definition
  • Definition of r-card
  • Where r-cards fit in Higgins Data Model
  • Proposed data format (schema) [Drummond]
  • How they work -- the BestBuy COA "VRM" use case

[1hr] Introduction to XDI and X3 [Drummond]

  • Very brief background on OASIS XDI TC
  • Explain how XDI is the protocol equivalent of the Higgins Data Model (and that's why I'm working with Paul and Markus and Higgins)
  • Show a few simple examples of X3 (using Markus' XDI Converter) to show how the XDI RDF Model can be used to implement the HDM and vice versa.
  • Point out the XDI RDF Model sections.
  • Finish by showing X3 for the same r-card scenario that Paul went through

[15min] [DEMO] XDI4J Code Walk-through [Markus]

  • Introduce XDI4J
  • Give a basic tour
  • Show the XDI Messenger
  • Show the XDI messages that would be transmitted for the BestBuy COA VRM use case Paul

Terminology & ISIP Interop [Paul]

  • Information Cards vs. I-Cards
  • Managed, Personal, and Shared --card categories
  • R-Cards, ISIP-M-Card, ISIP-P-Card --card types
  • UA-to-RP
  • UA-to-IdP
  • UA card import/export
  • Other interop issues
  • Discuss the development of a "portable ledger" format that would allow import/export of this ledger so that card history could be maintained (at least within Higgins selectors)

[30min] Five ways to integrate OpenID [Paul]

  1. OP Uses Cards for Auth (prevents phishing)
  2. Sxip OpenID Cards (OpenID claim type in managed cards or shared cards)
  3. OpenID Card: fills in pw at OP (prevents phishing)
  4. OpenID CP: OpenID OP into CP
  5. OpenID & Cards: Grand Unification

Thursday (ends at noon)

1.0 and 1.1 and... Plan

  • Review of outstanding bugzilla bugs (known bugs in 1.0)
  • Branch proposal:
    • Create branches (as we do now) for stable builds
    • Just keep marching towards 1.1, 1.2, 1.3 etc.
  • 1.1 Plan
    • Highlights

Introduction to Open Identity Network Non-profit [Paul]

RSA (April) and Catalyst (July) Interop Planning

  • Objectives?
  • Documentation of Higgins (eclipse-based, client-based, web-based) interop status/results?
    • The Higgins wiki is still circa June 2007
    • Need a matrix of support for Higgins 1.0
  • New functionality
    • R-Cards
    • OpenID
    • Selector Selector

Review and discussion of alternative to Microsoft's i-card logo [Paul]

  • Why we can't live with the current one
  • Road forward

Marketing & Outreach [Paul, Mary]

  • State of the art evangelizing: dataportability evangelism projects. We should be so cool. They have a killer YouTube video already.
  • [Paul] New http://higgins-project.org website
  • [Mary] Press release plan: coordination with Eclipse Foundation
  • Discussion of how we will publicize Higgins 1.0.
  • Outreach to independent OSS developers
    • What should we be doing? Should we have an plan?
    • What example CPs would get folks excited? A Twitter CP?
  • Outreach to other related efforts

Thursday afternoon - Unofficial Continuation

  • Whoever wants to stay, stay

Fodder

Links

Retrieved from "https://wiki.eclipse.org/index.php?title=Jan_29-31_Provo_F2F_Agenda&oldid=78349"

Back to the top