Shibboleth Developers

["Scott Cantor" <>]

> 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.

Yes, but those policies require administrator involvement. That model is 
fundamentally unusable for *some* use cases. The question is how to strike a 
balance between user and admin control, and whether Cardspace changes that 
balance.

But because of the way the claims model works, it is likely going to be 
impractical to pursue the multiple card model as a way to control release 
from the user's end unless the set of claims involved is distinct.

As an example, it's certainly not unusable if all the cards were distinct in 
terms of claims and only a single card lit up for an SP. That's exactly how 
it should work.

> > -- 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.

No, ee have a model where the IdP generally controls where the user goes and 
those locations are known in advance as part of controlling attribute 
release. That's very different from Cardspace in general.

> 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.

Yes, but those same demos have an effective ARP behind them of "release 
everything" and they leave it up to the user to decide.

That has problems, not least of which is that it makes entitlement values 
impossible to filter per site.

> > -- 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.

We can filter on values. CS can't do it by itself, which means the IdP has to 
continue to play the guard role. That makes "bag-like" attributes such as 
entitlement much different to handle in conjunction with a user consent 
model. That may be ok for entitlement, but then again it may not. It just 
depends on the use cases.

> 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.

Yes, but the fact that it's out of scope has deeper implications here because 
CS also has a UI. With the web, we control the UI.

> > 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 were comparing this to a model in which attribute release is entirely left 
to the user, which is how CS works today in most cases. The conclusion was 
that we will need a hybrid model where the IdP filters but probably with a 
much broader default ARP.

> > 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.

With SAML alone, the default is usually little or nothing. With CS, it may be 
quite extensive and include all of the usual demographic attributes because 
the user can decide whether to send them.

The idea was that we didn't know whether we could set up a policy that would 
depend on the protocol. If we can, you're right, having separate configs 
isn't needed.

> > 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.

It doesn't really have metadata in the sense we use it because the client is 
assumed to be the thing that trusts the RP. The client just tells the IdP 
where it's going to send the data. That makes it difficult for us to enforce 
policy based on SP identity without being able to reverse map from the 
location to an SP. This is exactly what Shib got wrong in the pre-1.2 days, 
and now we're kind of back to that mess.

>   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.

It's similar, yes. Additional lookup criteria. Personally, I ended up 
generalizing the metadata lookup to take a structure that can include an 
extensible set of inputs, so that probably works better as a model.

Brent did that kind of thing a lot with the security code, I know.
 
-- Scott