RE: LastModified [was: Re: I-D ACTION:draft-ietf-sacred-protocol-bss-01.txt]

Stephen,

I don't really see the need for the LatestLastModified since the client
could easily work it out from the individual LastModified values of the
credentials it downloaded.  Also, if the same CredentialType is used for
uploads, a client would have to set this value itself and we would be back
where we started.

Should we allow multiple credentials to be uploaded in a single
UploadRequest?

How about this variation:

     <complexType name="CredentialType">
       <sequence>
         <element name="LastModified" type="dateTime"/>
         <element name="Cred" type="sacred:InnerCredentialType" />
      </sequence>

     </complexType>

      <complexType name="InnerCredentialType">
        <sequence>
          <element name="CredentialSelector" type="string" />
          <element name="Payload" type="ds:KeyInfoType"/>
          <element name="TimeToLive" type="string" minOccurs="0"/>
          <element ref="sacred:ProcessInfo" minOccurs="0"/>
          <element ref="sacred:ClientInfo" minOccurs="0"/>
        </sequence>
      </complexType>

     <element name="UploadRequest">
       <complexType>
         <sequence>
           <element name="Credential" type="sacred:CredentialType"/>
         </sequence>
       </complexType>
     </element>

     <element name="DownloadResponse">
       <complexType>
         <sequence>
           <element name="Status" type="string" minOccurs="0"/>
           <element name="Credentials" type="sacred:CredentialType"
maxOccurs="unbounded"/>
         </sequence>
       </complexType>
     </element>

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Stephen Farrell
> Sent: 05 February 2002 14:43
> To: Gareth Richards
> Cc: [email protected]
> Subject: Re: LastModified [was: Re: I-D
> ACTION:draft-ietf-sacred-protocol-bss-01.txt]
>
>
>
>
> Gareth,
>
> Not sure which way we should go on this one (anyone else?). Agree
> that not depending on a client clock is good though.
>
> If we do take this approach then I'd probably want to take the
> LastModified from the inner sequence of credential structure just
> in case someone sometime wants to e.g. sign our credential
> structure (the problem of course would  be that the server
> would be modifying, making xml signing harder to do).
>
> Shouldn't be a problem to do that, just means having separate
> "inner" & "outer" structures maybe (partly including an earlier
> change) like:
>
>     <complexType name="CredentialsType">
>       <sequence>
>         <element name="LatestLastModified" type="dateTime"/>
>         <element name="Creds" type="sacred:OuterCredentialType"
>            maxOccurs="10" /> <!-- I *may* only be kidding about
> this:-) -->
>       </sequence>
>     </complexType>
>
>     <complexType name="OuterCredentialType">
>       <sequence>
>         <element name="LastModified" type="dateTime"/>
> 	<element name="Cred" type="sacred:InnerCredentialType" />
>       </sequence>
>     </complexType>
>
>      <complexType name="InnerCredentialType">
>        <sequence>
>          <element name="CredentialSelector" type="string" />
>          <element name="Payload" type="ds:KeyInfoType"/>
>          <element name="TimeToLive" type="string" minOccurs="0"/>
>          <element ref="sacred:ProcessInfo" minOccurs="0"/>
>          <element ref="sacred:ClientInfo" minOccurs="0"/>
>        </sequence>
>      </complexType>
>
> Questions:-
>
> - other suggestions?
> - any point in both LatestLastModified and LastModified?
>
> Stephen.
>
> Gareth Richards wrote:
> >
> > Stephen,
> >
> > Section 3.10 of draft-ietf-sacred-protocol-bss-01.txt
> describes the use of
> > the LastModified and PrevLastModified values in UploadRequest.
> >
> > I am concerned that there may be a potential for problems if
> we rely on the
> > clients to set this time when they may have inaccurate clocks.
>  It does not
> > appear as if there is a problem in detecting conflicts during
> upload since
> > the actual value of LastModified is not important (the server
> can treat it
> > as an opaque blob) but there may be potential problems on the client.
> >
> > If a user did the following
> >
> > Download to platform A, update from A, download to platform B
> >
> > then there could be some confusion if the clock on platform A
> was ahead of
> > that on platform B.  The user could be told that "your credentials were
> > last modified tomorrow".
> >
> > The same section states
> >
> >    Note: A server SHOULD ensure that the LastModified value in the new
> >    credential is reasonably accurate. If it isn't then the server
> >    SHOULD respond with an error message in which case, the server MUST
> >    NOT store the new credential.
> >
> > This seems to imply that it will only be possible for clients
> with clocks
> > in close agreement with the server to upload credentials.  It therefore
> > seems as if it would be safer to have a LastUploaded time
> maintained by the
> > server.
> >
> > I therefore suggest that PrevLastModified be removed.
> >
> > Section 3.2
> >
> > Second item be replaced with
> >
> >    - LastModified specifies the time at which this credential was last
> >      changed on the server.
> >
> > Section 3.10
> >
> > Remove first two paragraphs and replace PrevLastModifed with
> LastModifed in
> > second two.
>
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) +353 1 881 6716
> 39 Parkgate Street,                     fax: +353 1 881 7000
> Dublin 8.                mailto:[email protected]
> Ireland                             http://www.baltimore.com
>