Shibboleth Developers

["Alistair Young" <>]

Would it be possible to see the conformance doc? As part of our JISC
middleware project, Guanxi, we're investigating an IPDP that doesn't
require centralised resources for a federation. It also addresses the
concerns raised of multiple IdP for a user and how they change it.
It's also unclear how the domain cookie can be updated reliably if there
are hundreds or thousands of users authenticating and each IdP trying to
update the cookie at the same time.
Of course, there's also the issue of users disabling cookies, although
institutions could insist that cookies be enabled to use the system but
how ethical is this?
We're keen to allow simple SAML models to be used, where, for instance, a
couple of VLEs can be hooked up via Shibboleth or Guanxi, without the need
for extra resources such as a central domain server.
It would be nice to see how conformant our ideas really are as we are
working on an implementation of the Shibboleth protocol.
many thanks,
Alistair


-- 
Alistair Young
Senior Software Engineer
UHI@Sabhal
 Mòr Ostaig
Isle of Skye
Scotland

> Thanks for reviewing...my comments below.
>
>> - Applicable Shibboleth version is not mentioned anywhere in this
>> document (intentionally, I presume, but it's still a significant
>> omission)
>
> Intentional. There's an unpublished conformance doc, and there are no
> implementations of Shibboleth that are conformant. This is not about
> implementation, so why should we mention one?
>
>> - In Example 3.1.1.3, remove the URL encoding for clarity
>
> Why? Then the example would be wrong...
>
>> - In Examples 3.1.2.1, 3.2.1.1, and 3.2.2.1, insert indentation for
>> clarity.  Also, refrain from using default and/or redundant
>> namespaces.
>
> Will indent. I disagree about the namespaces, and I don't think any of
> them
> are redundant, but I'll check. I use default namespaces all the time. They
> save space.
>
>> - Not sure sections 3.3 through 3.7 should be called "profiles"
>> - Combine sections 3.3 through 3.5
>
> I'm reworking 3.3-3.5 back into the earlier sections (I agree), but they
> are
> all SAML profiles, IMHO. Except maybe 3.6, which just points at one. 3.7
> is
> probably going to be the basis of an actual submitted SAML profile.
>
>> - IMHO, section 3.6 should be omitted.  As written, it adds nothing to
>> the existing SAML2 "profile", which itself is vague at best.
>
> I think we, umm, disagree about the vagueness, or at least the necessity
> for
> it to be any less vague. "Doesn't solve an unsolvable problem" I would
> agree
> with.
>
> We have to reference it because this is a SAML 1.1 based set of profiles,
> and that's a SAML 2.0 profile that wouldn't otherwise apply.
>
>> Moreover, there seems to be a lot of overlap between the IdP Discovery
>> Profile and the WAYF.  Perhaps the two should be combined?
>
> I do, section 2.3 already allows for the use of that profile. The WAYF is
> a
> non-normative component, it wouldn't be appropriate to require one to
> utilize the SAML profile. It dovetails with it fine, since it's
> essentially
> usable as a shared domain. It effectively just offloads the SP's role of
> participating in the profile to it.
>
> -- Scott
>
>