Re: Fingerprint (was: RE: Missed Items)

Gareth, Stephen,

For clarity, I'd like to see the terminology changed to "last modified" (or
something similar) rather than "version number" which is used interchangeably
with fingerprint, most recently.

One could envision corner cases where a fingerprint (hash of credential) might
have slightly more utility than a time/date value with respect to performing
conditional replace or delete operations via the SACRED Upload command.
However, it's difficult to conclude that fingerprint should replace
last-modified -- ease of use is more important here, IMO.

Best Regards,

Dale Gustafson


Gareth Richards wrote:

> I can see no reason why the fingerprint shouldn't be a last modified type
> time value.
>
> If the credentials are small then you are right that the saving will be
> small since the client must go through the authentication process anyway.
> It may be worth it if multiple sets of credentials are supported.
>
> >
> > Ok, now I see what you're after. One issue - is there any reason
> > that the fingerprint should/should not be a digest? You're text
> > seemed (to me anyway) to imply that the fingerprint value would be
> > the hash of something, but I'd prefer that it be a time value, which
> > is more useful to human users.
> >
> > Also - I don't accept that we should try save bandwidth using this
> > trick. There's no rountrip savings involved since the check also
> > has to be secure. However, you're point about modifications is
> > valid - I'll add in a bit of text about that.
> >
> > Stephen.
> >
> > Gareth Richards wrote:
> > >
> > > The reason the client would check is to reduce the number of credential
> > > downloads. If the fingerprint isn't used then the credentials
> > would have to
> > > be downloaded each time to ensure the current version is used.
> > >
> > > The fingerprint could also be of use in detecting conflicts.
> > For example,
> > > download to platform A, download to platform B, update from B,
> > update from
> > > A.  The server could detect a conflict on the second upload.
> > >
> > > >
> > > >
> > > > I think this is possibly ok, but I want to think about it for
> > > > a bit (I'm a bit wary of (c) below - can't see why a client
> > > > would bother checking?)
> > > >
> > > > Stephen.
> > > >
> > > > > 1. Fingerprint
> > > > > The I-D has a LastModified element in the credential format
> > > > (section 3.2).
> > > > > The proposal is that this be replaced with a fingerprint
> > which would be
> > > > > used as follows:
> > > > >
> > > > > a) Returned by the server in the upload response (Framework
> > > > section 5.1).
> > > > > b) Optionally sent with the credentials in an upload request.
> > > > If it is not
> > > > > included then the credentials are replaced unconditionally.
> > > > > c) Optionally sent along with the credential selector in a download
> > > > > request(Framework section 5.2).
> > > > >
> > > > > The intention is that if the client has locally cached
> > > > credentials then it
> > > > > could use the fingerprint to conditionally download
> > > > credentials if they are
> > > > > newer.
> > > >
> > > > --
> > > > ____________________________________________________________
> > > > 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
> > > >
> >
> > --
> > ____________________________________________________________
> > 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
> >