shibboleth-dev - Re: Replay handling/caching
Subject: Shibboleth Developers
List archive
- From: "RL 'Bob' Morgan" <>
- To: Scott Cantor <>
- Cc: "'Shibboleth Design Team'" <>
- Subject: Re: Replay handling/caching
- Date: Sun, 28 Jul 2002 02:42:07 -0700 (PDT)
On Sat, 27 Jul 2002, Scott Cantor wrote:
> But this is only half the real solution. We should modify (or extend)
> the Shib architecture, and append a third parameter to the HS request
> format, a time parameter containing the time of the request.
I'd kinda like to see proposed arch doc text before modifying on-the-wire
formats.
The request generator puts in the time the request is generated, in what
format, with what resolution? How is the HS (or whatever we decide to
call it other than HS) supposed to process this?
This is only an indication of clock skew at the target? Seems to me this
doesn't apply at all in the case of the local-nav site, or of the
redirecting WAYF, both of which would have their own clocks separate from
the target. If it's supposed to help fix the multiple-POST problem I
guess I don't see how it does that.
If we're modifying the request format I have a whole pile of candidate
params, basically everything pubcookie has now or might have shortly:
login-policy, don't-use-SSO, don't-prompt-user, etc. The more general
question perhaps is extensibility of this format and registration of these
param types and values.
- RL "Bob"
------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at
http://archives.internet2.edu/
------------------------------------------------------mace-shib-design--
- Replay handling/caching, Scott Cantor, 07/27/2002
- Re: Replay handling/caching, RL 'Bob' Morgan, 07/28/2002
- RE: Replay handling/caching, Scott Cantor, 07/28/2002
- Re: Replay handling/caching, RL 'Bob' Morgan, 07/28/2002
Archive powered by MHonArc 2.6.16.