Shibboleth Developers

["David L. Wasley" <>]

I think you're correct - I was referring to the entire bundle-o-bits flowing 
from the HS to the SHIRE by way of the user's browser.  The "handle" per se 
is inside that BoB.  I thought there were additional things like TTL, etc., 
that mitigated against replay.  (Been a long time since I looked at the Shib 
doc ;-)

I assumed that Von was suggesting inserting that entire BoB into an x.509 
object that the Grid target would accept.  In the finest Grid tradition, I 
believe the user manufactures (signs) their own x.509 object.  So, if the 
Grid target is happy with that object, and the BoB inside is also 
sufficiently trustworthy, then the rest is easy (I think).

Of course, this scenario is a "replay" of sorts but seems like it ought to 
work iff (it's within the TTL) && (the IPaddr of the signer's platform is the 
IPaddr to which the HS forwarded the BoB).

        David

PS: Is the BoB that I'm describing == the SAML Bearer Assertion?  Or ...?

-----
At 4:13 PM -0500 on 1/16/04, Scott Cantor wrote:

> > The Shib handle has a lot of built-in defenses against
>> replay, etc., so we believe it's pretty trustworthy.
>
>The Shib handle, or the SAML bearer assertion? Please lets make sure our
>terminology is clear here.
>
>The handle is a name. It has no replay protection or much of anything else,
>and sharing it around freely would mean that any valid requester to an AA
>could get attributes about that handle for the life of the handle (we should
>be scoping it to a given target, but we didn't, mainly because we didn't
>have a language or protocol support to express who the target really is).
>
>I think we're just miscommunicating on the terms, but I want to make sure.
>We really need to rewrite the Shib arch doc to just eliminate all this extra
>terminology, it's just confusing now. We're SAML, plain and simple. Well,
>sort of simple...
>
>-- Scott