View source for 2008 Provo F2F IdAS & IGF Design Session Notes

Session Notes

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