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

11:40 [20min] Separating out the Selector Authentication Service [Drummond]

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

Lunch

[15min] Review of Eclipse Release Review Slides [Mary]

Mary will send slides to list

Wednesday Afternoon

[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).

> > Can we add /Resource/*config.xml to Plugin without impact to
JARs?
> > How do we deal with log4j.properties? It is in the redist plugin
-

how can we change it without changing plugin code?

[30min] PKCS5 vs. ISO10126 Encryption/Decryption [Mike]

Should always: Encrypt via PKCS5 and Decrypt via ISO10126
Encrypt Decrypt
Relying Party No* Yes
Identity Selector Yes No*
Identity Provider Yes Yes
*Current implementations may not use encrypt or decrypt but future ones may.
The IXMLSecurityExtension should be broken into:
IXMLSignatureExtension
IXMLEncryptionExtension
IXMLDecryptionExtension
The xmlsecurity.apache should be broken into
xmlsignatureextension.apache
xmlencryptionextension.apache
xmldecryptionextension.apache
The xmlsec-1.4.0 (1.4.1) should not be in the redist plugin.
It should be in the various xml*extension.apache plugins.
The name of the config.xml (IBM vs. Sun(default)) should be a configuration setting