Shibboleth Developers

["Tom Scavo" <>]

On 3/8/06, 

 
<>
 wrote:
>
> We'd
> like to ask people to review this document, and provide comments and
> feedback via email.

To put my comments in perspective, I am a developer and architect (not
a deployer or administrator).  Our project (GridShib), which ends Q1
2007, has settled on Shib 1.3 as a development environment.  It is
unlikely Shib 2.0 will figure prominently in our final project report.
 For the next year, our interest is primarily in the backporting of
Shib 2.0 features into 1.3.

> This release will be interoperable with Shibboleth 1.2 and 1.3 service
> providers, but will drop support for Shibboleth 1.1.

I assume you mean the Shib 2.0 IdP will interoperate with all SPs
(except 1.1), but that the Shib 2.0 SP will only interoperate with the
Shib 2.0 IdP.  Will the Shib 2.0 SP consume SAML 1.1 assertions?

> Identity Provider
> Enhanced installation, deployment, and manageablity features:

FWIW, I agree with Jim on this point: Shib 2.0 should "just work" out
of the box, which necessitates a bilateral deployment.

>     * Extensions to support the Australian MAMS Shibboleth ARP Editor
>     (ShARPE) and Autograph tools

What is needed is a tool that takes existing ARPs and metadata as
input and produces new ARPs as output.  Assuming the metadata calls
out SP attribute requirements, the tool should provide a UI for
administrators to check off trusted SPs and further check off the
attributes to be released to those SPs.  Does the MAMS ShARPE tool do
this?  (If so, sign me up! :)

> Enhanced Attribute Authority features:
>
>     * Inclusion of name identifiers in the attribute release policy

The ARP tool mentioned above would automate this as well.

>     * New eduPersonTargetedID implementation that supports
>     database/directory backend in conjunction with support for SAML 2.0
>     persistent identifiers

Please don't let anyone talk you out of this important feature.  In
fact, it is likely we will backport this feature to 1.3, so the more
modular you make it, the better.

> Other new features:
>
>     * Support for additional name identifiers, in particular an
>     implementation of SAML 2.0 persistent name identifiers

I assume this and ePTID will be interchangeable.

> Service Provider
> This release will provide both a C++ and Java (Servlet 2.3 or better)
> service provider with similar feature sets.

Awesome!  If the Java SP can consume SAML 1.1 assertions, we will
almost certainly find use for it in our project.

> Additional features will include:
>
>     * Support for SAML IdP cookies as defined by the SAML 2.0
>     specification

Maybe I'm missing something but I don't see the utility of this
profile.  In any event, can/should this be pushed back to Shib 2.1?

> Unassigned Features
>
>     * ARP and Attribute resolver management UI

How is this different than MAMS ShARPE?

Can you add these to the "Unassigned Features" list?

- A robust mechanism at the SP that exposes a signed attribute
assertion to applications
- A tool that produces IdP metadata from the underlying configuration
- A default domain (scope) value baked into the IdP config (required
for the previous tool)
- Support for AuthnRequest/@IsPassive [Shib 2.1 feature?]
- Support for LOA attributes

Thanks for sharing your plan,
Tom