Shibboleth Developers

[Von Welch <>]

I think Scott's comments covered most of this but I'll add a couple...

David L. Wasley writes (00:53 January 15, 2004):
 > Please see below ...

<snip>

 > >Alternative #1: Credential Pull Model, No Privacy
 > >
 > >In this model, there is no session concept.
 > >
 > >* User (or process running on the user's behalf with delegated
 > >credentials from the user) authenticates to target service with normal
 > >Grid credentials (EEC or Proxy Certificate and associated private
 > >key). Through this authentication the target service established the
 > >subject name of the user.

<snip>

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

No, just that the target service accepts identity credentials from the
user's origin domain (e.g. it trusts the CA that issued the user's
EEC).

 >  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. (+)
 > 
 > The second problem is simpler: a different API to the AA.  This would 
 > be a simple query interface where the asker is identified by means of 
 > a trusted cert (no mean feat but that's another story).  As with any 
 > query to the AA, there is default information that it will release to 
 > any asker but if the asker is "known" to the AA, then it may have a 
 > specific ARP to apply to the query.  Again the crux is the identifier 
 > by which the asker seeks to be recognized.

Right. I think we've had discussions in the past if Shib could use a
Subject name instead of a handle. The answer I believe I've gotten is
"yes with some work".

 > (+) I suggest that this problem be addressed by asking the GRID user 
 > to apply for GRID services using their "home org" EPPN.

<snip>

 > Sounds like a Kerberos ticket ...

A lot of things do :-)

<snip>

 > >--------------------
 > >
 > >Alternative #3: Temporary credential model with privacy

<snip>

 > Looks the same as #2 but the query is done with a "handle" instead of 
 > an "EPPN."

Yes. If you don't want your identity known, go get a temproary
identity and throw it away when you are done. Only trick is tying it
to your attributes for the duration of use.

Von