Shibboleth Developers

[Nate Klingenstein <>]

Obviously it would've been nice to have gotten this feedback in  
sooner, but it only landed in my own hands now.

> I don't think "Terms of Use" justifies a rev of the spec. Doesn't seem
> like "Terms of Use" is substantially different than a Privacy
> Statement (<mdui:PrivacyStatementURL>). If you really feel like you
> need "Terms of Use," why not just add it as an extension of the
> <mdui:UIInfo> element?

It's not substantially different, which is why I preferred the former  
term as the more general choice.  But since the draft is already at  
CD, I agree that it's probably more trouble than it's worth.  I'll  
advise them to just interpret <mdui:PrivacyStatementURL> broadly.

> If I understand correctly, you want a language-specific description
> for each attribute? Well, there's no good way to do that as others
> have already pointed out, but I think it's a bad idea anyway. If you
> have to write words on the user interface to explain to the user
> what's going on, then it's not going to work. Have we learned nothing
> all these years of building discovery interfaces? (sorry :)

Their intent is to build an interface that supports the optionality of  
<md:RequestedAttribute> in consent, and "isRequired='false'" is almost  
impossible to interpret without explanatory text.  It may be that the  
optionality was a bad idea in the first place, but without that or an  
<OR>/policy logic, I don't see how you would support "a persistent,  
non-reassigned identifier".

I'll suggest they use localized <md:ServiceDescription> elements as  
per Scott's suggestion and if I get further pushback, I'll bring it  
here.

> The suggestion to add OR logic to SP attribute requirements is a good
> one that's sorely needed, but I suggested that six months ago and got
> strong pushback. The argument against was that that feature
> essentially requires a rewrite of <md:AttributeConsumingService> and I
> think that's still a correct assessment. If you do that, however, I'd
> like to add my favorite use case for consideration: "a persistent,
> non-reassigned identifier."
>
> All of this is coming late and at the last minute. Within the InCommon
> federation, we have set a plan in motion to rollout <mdui:UIInfo> and
> <md:AttributeConsumingService> by April 2011. The latter can't be
> extended but the former can. In either case, anything that the
> community decides to do will not affect the work we have planned. If
> you modify the SAML V2.0 Metadata Extensions for Login and Discovery
> User Interface, however, you're gonna set back consent by at least six
> months, not just within InCommon, but worldwide.
>
> Tom