Shibboleth Developers

[Chad La Joie <>]

 wrote:
> -- the CS model expects a user to have a few cards, from different 
> issuers. We're thinking about a model where a user would have a few 
> cards from the same issuer (the different cards would release different 
> attributes).

If you're thinking along those lines I would suggest changing directions 
right now.  The usability of a model like that would be horrendous.  Why 
would we even need it?  We have a mechanism that we already use for 
controlling the release of attributes that is independent of the 
credential that is used to authenticate, the attribute filter policies.

> -- in a standard Shib model, ARPs within the IdP control attribute 
> release; they are typically managed by a site. In the CS model, the user 
> trusts the RP, so the IdP is also supposed to trust the RP, and do what 
> the user instructs it to do.

Again, we have this today.  I feel like you are, again, confusing policy 
based filtering with user consent.  Every demo I've seen of CS has the 
user consenting to the release of some set of data.  The RP can request 
particular attributes just like a SAML 2 SP can but that's orthogonal to 
consent.  Conflating these issues is not going to help anyone.

> -- Shib ARPs were designed to allow the filtering of multi-valued 
> attributes. CS doesn't provide any such filtering. A card might say 
> "release entitlement" -- does that mean we release every value?

Again, there is no difference between what we have now and what CS is 
doing.  SAML SPs can already request specific attributes, that is, an SP 
can already say "give me entitlement".  I don't know why a CS RP saying 
the same thing would cause the IdP to behave any differently. 
Policy-based filtering (or pretty much any other policy evaluated by the 
IdP) is out of scope for the CS spec just as it's out of scope for the 
SAML spec.

> There was a strong feeling that the ARP engine should somehow be 
> involved in the attribute release process.

Umm...  the AFP engine IS the attribute release process.  That's not 
going to change.

> We decided to provide a site with a set of templates to support the set 
> of cards they decide to issue.
>
> Q -- will Spring allow the use of two different ARP engine + config's? 
> One for standard Shib, and one for CS (eg have different default release 
> policies for these two situations?)

It would, and you could do it today, but this is completely unnecessary.

> Q -- does the ARP engine know the protocol that's being used (eg if 
> SAML, release nothing; if CS, allow user to control)

Yes.

> 4) RP Identity -- Because CS does not have a concept like entitIDs, our 
> sense was that we need to extend the metadata interface, to allow 
> looking up by endpoint (which is what CS does provide)

Well I haven't seen any examples of CS metadata yet so I have no idea if 
its metadata will even make sense to access through the current 
interfaces.  I suspect its probably different enough to make it a pain. 
 If, however, it's not or we choose to create a SAML metadata extension 
for CS protocol support I don't think this will be an issue.  I already 
have to go in an change how metadata is being handled in order to 
support SP issued artifacts.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
,
 http://www.switch.ch