Shibboleth Developers

["Tom Scavo" <>]

On 7/31/06, Scott Cantor 
<>
 wrote:
> > No, not in any version I'm familiar with (and I think I've
> > read them all).
>
> Ok, I'll review again, I could have sworn there was a client->SP step in the
> sequence diagram.

Yes, in a non-normative section describing a motivating use case.
Those steps are not constrained by the profile, however.  There is a
large, gray box surrounding the pair of steps that are addressed in
the profile:

http://www.oasis-open.org/committees/download.php/18058/sstc-saml-x509-authn-attrib-profile-cd-02.pdf

The other steps are there simply to give the problem some context.

> If it's actually a different query profile from Shibboleth's, then yeah,
> we're both overloading the <AttributeService> element for SAML 1.x. Both
> wrongly, arguably.

Well, we can still fix GridShib.

> What else is really in the current Booz-Allen profile beyond "MUST sign,
> MUST encrypt, etc."? Why is that really a different profile?

I was hoping you'd ask that eventually :-)  The BAH profile that just
underwent public review is of little use to GridShib (and not because
it's SAML V2.0).  I've rewritten it three times now.  The latest
version is a layered thing that can be reused for various purposes.
The basic idea is to have a set of profiles for "X.509 Subjects", that
is, SAML assertions and profiles built around the X509SubjectName
identifier.

I think I know what you're going to say :-)  "You have to invent a
whole set of new profiles just for X509SubjectName!"  The short answer
is yes.  Like LionShare and Dorian, we need a profile for assertions
describing X.509 subjects.  I think the most recent revision of the
BAH attribute sharing profile covers all these use cases.

> > If every AttributeService endpoint were identified by a URI
> > in metadata, there wouldn't be a problem.
>
> The "profile" is implicitly captured by the element name. This is how the
> schema works. if you need a different profile, you need a new element name,
> generally. Or possibly just extension attributes to indicate extension
> behavior, depends on the degree of change.

I hadn't considered an entirely new element on the IdP side (we
already have one on the SP side).  That's an alternative to an
extension attribute, I guess.  I'll have to think about that.

> So <md:AttributeService> means the SAML 2.0 profile (or more recently it can
> also mean the SAML 1.x query).

Well, but there is no SAML 1.x attribute exchange profile.  Does this
mean that <md:AttributeService> should not be allowed in SAML 1.x
metadata?

> Anything else shouldn't really use that element unless it's substantially
> the same and backward compatible with it.

Does an extension profile qualify?  (Not sure when a profile warrants
to be called an "extension")

Tom