Shibboleth Developers

At 7:59 AM -0500 9/25/03, Tom Barton wrote:
> This thread leaves me confused as to what the criterion should be 
> for the AA to permit release of an attribute, beyond what's in its 
> attr release policies. Do we want to have assurance that the 
> attribute is being released to the target so that it can perform a 
> service for the user who is presently waiting for that service to be 
> rendered? Or, do we want the design to inherently defend against a 
> target that is abusing the trust invested in it by policy? Or ... ?
>
> Shib v1 requires the user to pass nearby the AA to obtain a dated 
> artifact of that occurance which the user gives to the target to use 
> to get user attrs from the AA. This proof of presence is of the 
> "guess a number between 1 and 2^n" variety, arguably undermined 
> somewhat by how the HS is operated (eg, gives out the same handle 
> for the same user every time).
>
> Here are three approaches offered only to spur thinking about what 
> degree of assurance the AA should be satisfied with. They are not 
> realistic design proposals. (1) PKI ala Ryan's posting, or other 
> modification of client software to enable direct communication 
> between HS and client; (2) endow AAs with some type of logic for 
> detection of errant behaviour of the external components with which 
> it interacts; (3) include a "secured" xmpp/jabber server in the 
> origin site architecture and require users to have their presence 
> client up in order to receive shibbolized service (perhaps the AA 
> would message the user, or perhaps the AA would verify the target's 
> assertion that "user is active on ip address blah right now").

With the current shibboleth architecture of using opaque handles, and 
the web-centric implementation, there's clearly a range of approaches 
that could be used to approve (and  maybe secure) attribute release

- the current HS gives out unique handles to each target; the AA, 
after authenticating the SHAR, could verify that that the received 
handle was given to that target....

- as Scott noted, perhaps the SHAR could  include the fully signed 
Authn Assertion in the Attribute Request (and not just the unsigned 
Subject element from the Authn Assertion). Then, the AA could ensure 
that it handed out the Authn Assertion

- we could implement Dynamic  Attribute Release -- essentially, the 
AA would cause a redirect of the user's  browser every time 
attributes were requested, and the user would have to approve the 
release...... (clearly, tho,  this  is web-centric)

And, as Tom and David have noted, there are various ways to extend 
the current Shib architecture.....

right now, tho, I'd like to keep the conversation focused on the 
proposed WebDAV scenario ....

where the client is something other than a web  browser......

how would we like this to work?

-- modify the webdav  client to do shib in some fashion?

-- or, shib protect the webdav target, but have the target supply 
something other than a handle to the AA, when requesting attributes?

-- I  don't think its useful to say that the AA would only use the 
default policy in this case -- presumably, that releases  only a bare 
minimum of attributes,  and presumably something more than  that 
would be needed to access  protected webdav areas....

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

   http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--