Shibboleth Developers

["David L. Wasley" <>]

Scott, Sorry to go over old ground - I've missed some of the earlier 
discussion.

By "simple query API" I mean as opposed to the complexity of the 
"handle" interface where there are a lot of checks, etc., to avoid 
malicious user behaviors.  In the simple case, an application simply 
wants some information related to something it knows.  My comments 
were based on the assumption that the complex handle interface was 
not generalized to be able to accept the simple query but I'm glad to 
hear that that is not the case.

Yes - what I am describing is a lot like a database query but not 
nearly as complex.  No following DITs or conditionals; just "here's 
an identifier - what can you tell me."  The advantage and value that 
the AA brings as a front end to the enterprise directory is precisely 
in the ARP capability.  It can provide a much more policy-driven way 
to decide what entity can get what data.  And - it can take into 
account the subjects preferences as well (as you know).  So - that's 
why I've always said that the AA is the most important piece of Shib.

More below...
-----
At 10:07 AM -0500 on 1/15/04, Scott Cantor wrote:

>  > This model assumes, in Shibboleth terms, that the user's Origin
> >  Domain is the domain of the target service (step 1 above).  The twist
> >  is that the Origin Domain is not authoritative for at least some of
> >  the attributes of interest.
>
> I think it's quite tractable today with attribute acceptance policies that
> finely control which values you accept from whom.

What I was getting at is that the "origin" (which is also the 
"target" in this case) doesn't even have the data - it is going to go 
to a third party to get it.  Not that this is awful, just a twist.

> >   From a Shib point of view, the "target" in this case wants to be able
> >  to ask a particular AA at any point in time to release information
> >  about some entity.  There is an assumption that the target has an
> >  identifier of some sort for the subject that is recognized at the AA
> >  -- the cert Subject Name may or may not be that identifier, depending
> >  on how it was created.  So the subject identifier is the first
> >  problem. (+)
>
> Why is that a problem? The AA has factories for different types of names and
> Walter is extending that now. And adding ARP support for controlling release
> based on the type of identifier...

See my comments at the beginning.  The issue is really: what set of 
identifiers is the AA interface able to accept?  For example, if the 
app queries on the human name, e.g. "John Smith", and there are 9 of 
them in the AA's database, is the AA prepared to return an 
appropriate error message?

In the example Von gives "the user authenticates to the target" so 
whatever identifier the GRID target has for that user somehow needs 
to be understood by the user's home campus AA.  That's why I 
suggested that the GRID use the home campus EPPN as their identifier 
for GRID members.  It will work nicely in a query to the home campus 
AA.

> >    - is the concept of "session" important WRT the simple query API?
> >  In other words, is there a concern that a query should be the result
> >  of a user action and not an arbitrary, random event initiated by the
> >  target?
>
> We've discussed it. We're not fully set on how to repesent this in the ARP
> yet. We've debated a really simple binary Presence/NoPresence vs. more
> complex approaches.

It is certainly simpler to assume that it's OK for a query to the AA 
to occur at any time for any entity.  The ARP should protect the data 
appropriately in most cases, I think.  The one obvious problem is 
just what occurs today with campus "phone book" directories - 
harvesting.  I think the only mitigation for that is to recognize 
that sort of anomalous behavior and Do The Right Thing.

Thanks,
        David