Chad La Joie – from SWITCH

Shibboleth 1.3 reaches end of life on June 30th 2010 – there will be absolutely no support after this time – so you should be planning to have upgraded to Shib 2.0 by this date!

Next release of Shibboleth IdP is 3.0 – this is not a major rewrite – do not wait to upgrade! Main goal – to clean up APIs hindering new work. Also includes n-tier delegation support and non-browser based authentication.

Discovery Service 2.0

• incorporation of feedback from JANET funded usability study
• support for centralised and page-embedded models
• HTML/CSS/JavaScript that can be dropped into an SP to render a discovery interface

Chad claims that if you give SPs just a snippet of HTML or JavaScript, they are happy to embed it in their interface (not sure about this – what if they get competing demands from different federations)

N-tier delegation

What? – user logs into the portal, and the portal logs into back-end services as the user – this is delegation

Goals

• allow service to log in to the back-end server as the user
• control which services can impersonate the user
• keep a complete audit trail of impersonation
• and other stuff …(sorry, missed this)

Attribute Aggregation

What:

• aggregate user attribute from home organization and other sources such as professional organizations

Goals

• Allow SP to pull in attribute from multiple attribute authorities (IdPs)
• use existing attribute release/acceptance policy mechanisms

Status

• latest SP has support out of the box
• 2.x IdP has support out of the box
• currently only identifiers shared by AAs and SPs are supported

Future work

• determine if non-shared identifiers are usable/supportable
• determine if IdP aggregated attributes is useful and tenable

How does the SP know where to aggregate attributes from? At the moment can either be hardcoded in SP, or sent from the IdP.

OpenID Support

Goals:

• support XRD 1.0, Open ID 2.0, PAPE, Simpler Registration, Attribute Exchange
• use existing trust layer to create trust between OpenID entities
• use existing attribute release mechanism

Status

• XRD 1.0 now out of community review
• basic support for OpenID 2.0 and PAPE support via proof-of-concept IdP plug-in
• trust equal to standard deployment of Shibboleth
• OpenID protocol dos not support certain advanced trust models
• No SP support planned

Future Work

• develop real IdP plugin based on IdP v3

Buzzwords: User-centric identity

• Two views of user-centric identity
• 1. Purist – all data about a person is property of, should be kept by, and should be released by the person – i.e. OpenID model
• 2. Identity 2.0: User picks which account and associated data should be used with which service – i.e. Cardspace model
• But – users aren’t authoritative – or trustable source of, for most of their data
• most user’s can’t run their own identity provider
• most user’s have a hard time understanding relationships between attributes and the service provider

The goal should probably be a release consent model added to the Identity 2.0 view – e.g. Shibboleth + uApprove  (http://www.switch.ch/aai/support/tools/uApprove.html)

Buzzwords: Cardspace

CardSpace generally refers to two things:

• Microsoft’s evolution of Passport in to a decentralized service – know by MS as the ‘identity metasystem’
• Microsoft’s client for the service is the the only thing that Microsoft calls CardSpace

Primary focus on avoiding phishing.

However – now Microsoft now doing server-side implementation called ‘Geneva’ – which is the non-interoperable, spiritual successor to ADFS. This does not currently interoperate with other products – including MS own Cardspace selector.

MS-hosted ‘cloud’ Exchange, SharePoint and storage service have Geneva support – and SharePoint 2010 will have support as well.

MS have asked Shibboleth team to add Geneva support – which they would do if MS would actually make the specification available!

Buzzwords: OAuth

OAuth is an access delegation protocol:

• You login to Service B. Service B wants your information from Service A. You login to A, get a token, and give it to B. B uses  the token to get information from A.
• OAuth is independent of the means by which a user is authenticated of the format of the token
• so OAuth is orthogonal to federated identity management (although you could use things like n-tier delegation to achieve this)
• OAuth is current under-specified
• creating interoperable implementations tends to be a trial-and-error exercise
• IETF WG attempting to provide a more clear standard http://www.ietf.org/dyn/wg/charter/oauth-charter.html