Shibboleth Developers

["Scott Cantor" <>]

> 2. Support for delegation
> -------------------------
> We thought that this would be a Shib 2.0 item, but it looks like it is
> definitely deferred to 2.1.
> However, in the roadmap it is neither mentioned for 2.1 nor under
> 'unassigned features'.

It's listed under 2.1 as "Additional features may include standards based
extensions to support web and SOAP applications and related use cases."

That's what we're talking about, but that wording doesn't sound as good as
it did on the phone when we worked it out. I suspect we'll reword again. I'm
trying to avoid the word "delegation" because it sends up flags with
security people. Delegation is roughly giving somebody permission to do
something. This is not about the giving of permission, it's about the
representation of that permission and exercising it.

> Our desired time frame is
>  - delegation specification in Q3 2006
>  - beta implementation in Q4 2006

Implementation is difficult to even comment on, but I think my rough answer
is that Liberty ID-WSF 2.0, suitably scoped, is the only emerging standard
means of using SAML for this, so a specification is forthcoming by end of
Spring. There isn't a whole lot for anybody here to specify other than a
laundry list of what pieces are required to solve which use cases.

> Further comments on the road map:
> 
> 1) The most useful new feature for us is  support for 'some basic
> authNContext' as we will introduce strong authentication in our
> federation in Q3/Q4.
> Could you please elaborate a bit what where 'some basic authNContext' is
> limited in contrast to 'authNContext'?

I think we're hoping the community does this. We honestly don't know what
people want. The AuthnContext system is extremely complicated, and so far
deployment of it is very limited in Liberty, dating to its inception there.

> 2) Supporting compatibility with 1.2 SPs is great in terms of smoother
> migration of our operational federation from SAML 1.1 to SAML 2.0.
> Otherwise 2.0 could only be deployed at IdPs when all 1.2 SPs were
> eradicated.

There just isn't even a question about this item. The real issue to me is
that WAYFs will not handle a multi-protocol environment properly without a
lot of extra work.

At *best*, using centralized discovery would require a new protocol be
specified to get the IdP back to the SP. In other words, the WAYF model
would explicitly need to change from SP->WAYF->IdP to SP->WAYF->SP->IdP.

As you can see, once you accept that the WAYF is really part of the SP, that
drops to SP->IdP.

> 5) It was once mentioned that the Java SP might be released before the
> C++ SP. Is that still under consideration?

I don't think so, no. There is no release planned until the overall 2.0 code
base is released, in order to ensure some degree of feature parity. One of
the big downfalls of the last attempt was that the SP was in major flux when
the work began.

-- Scott