Shibboleth Developers

["Scott Cantor" <>]

> Which profiles have to be implemented by Shibboleth? Just the  
> optional features and ECP, or all the others as well?

I'm not sure I understand the question. ECP itself is orthogonal to the
proposals in this document, they function at a layer above either of the SSO
profiles. Since there is no commitment yet to implementing any of this, the
only things I'm confident that Shib 2.0 will support are Browser/SSO,
AttributeQuery, and probably ECP in some fashion.

ECP itself has some problems as it's currently defined, particularly the
IdP/client interaction. There's not enough spec there to do the
authentication step without knowing what the client will handle, so I
suspect that's going to change at some point if ECP ever gets any traction.

> Section 2.1, Lines 189-226
> Is it right that the explanation of sequence (missing) diagram is a  
> combination of the SAML 2.0 SSO profile in general and the ECP  
> profile when starting at Item 4. If this is the case, shouldn't they  
> be separated?

Again, ECP has nothing to do with this. This is all independent of that. The
point of the section, which I'm not sure is even worth keeping, is to
highlight steps 6-8 which are essentially additions to the current SSO
profile.

I think it's more confusing than helpful and maybe should be an example
section down below in which a specific use case is explored where SSO is
combined with delegation.

> Section 3.3
> It's not clear to me about which kind of use cases this profile (SAML  
> Token Service) addresses. Nay examples? Is this a complement or an  
> extra profile?

It is an entirely separate profile. It is (admittedly) analagous to WS-Trust
except it maps everything to SAML instead of everything to everything. It
enables arbitrary clients to request arbitrary assertions for arbitrary
reasons. It doesn't assume particular flows afterwards. It doesn't make the
client a relay point between two servers. It does a lot of things and it's
complex to define.

Liberty also has a stated need for such a service, and my preference is for
them to define it, ideally as independently from the rest of their WSF stack
as possible. Their use of WS-Addressing in the new specs suggests that this
might be possible.

It also overlaps somewhat with the IdP half of the ECP profile, or at least
needs to be distinguished from it and Liberty has to work that through
anyway.

As far as a specific use case...well, I guess the LionShare stuff would be a
possible example...stand-alone client is getting assertions that it's going
to send somewhere, but the IdP needn't really inject itself tightly into the
whole picture if you trust the client to ask for what it needs and be
responsible to the user for not misusing the data. So the profile is just
"LionShare client requests assertion(s) from SAML token service" and the
rest is out of scope.

> Section 3.4
> This is an excellent extra profile, which will be very useful  for SRW  
> and WSRP use cases in particular. It can also be seen as a reference  
> specification for other protocols.

Well, the problem is, why do we need this? Shouldn't somebody else define
this? Doesn't Liberty already define it? Partly I'm defining it because I
want to highlight the fact that I don't want to define it. The other reason
was so I'd have an excuse to learn enough WSS to be taken seriously when I
say something about it. That wasn't fun, but it was probably necessary.

Shibboleth 2.0 IdPs probably should be able to produce SAML assertions that
are usable in the relevant profiles that people define, but I'm just not
sure we should be defining them all at this point. But somebody better do
it.

I'm more comfortable, frankly, with Internet2 contributing profiles of SAML
with other non-web services application protocols, than with stepping into
the web services swamp. Using SAML as a SASL mechanism, for example.

> Can we assume this will be Shibboleth 2.0? Any idea about a possible  
> roadmap? How can we contribute?

No, I don't think you can assume that yet. The biggest issue that I see is
that 90% of this is already defined (or being defined) by Liberty WSF 2.0,
usually more generally. So the onus is on the community to explain why we
need to implement something that competes with something that supposedly
will have at least some vendor tool adoption. What Liberty definitely
doesn't have is open source.

But maybe we should be spending resources implementing parts of that instead
of inventing something new. I don't know.

I think the best contribution at this point is for people to evaluate some
of this material against their use cases, and also to get familiar with the
world out there that seems to be driving this stuff. If WSF 2.0 was public
yet, I'd be suggesting people look at it, but unfortunately it's not out
yet. That in and of itself is frustrating, I don't like Liberty's closed
process. It makes me look bad for continually suggesting that we're
reinventing the wheel because nobody wants a closed wheel.

-- Scott