Re: Credential DELETE Operation

Hi Stephen,

I'm also in favor of adding a DELETE message at this time.

Agree with your suggestion to define a specific DELETE-ALL message.

Best Regards,

Dale Gustafson


Stephen Farrell wrote:

> Hi Gareth,
>
> I guess I'd still have my earlier gut reaction that since its
> late in the day and we don't absolutely need to make the change,
> I'd be against doing it (though not at all vehemently). If I
> had to offer a technical argument against this I'd say that we're
> just adding more error cases to the server, which is therfore less
> likely to interop smoothly with diverse clients (not that that's
> a winning argument in this case, I agree - OTOH, I don't see a
> winning argument for making this change either, so we're even:-).
>
> If others want to add the explicit delete message then please say
> so and once we know the concensus we'll work it in or not as the
> case may be.
>
> Meanwhile, if we did make this change, where'd be the text that
> tells the server what to do when it gets an UploadRequest
> containing zero credentials? Secondly, if we were making this
> change, I'd argue that we include an explicit "delete-all"
> rather then a sort-of-implicit one as below.
>
> Stephen.
>
> "Richards, Gareth" wrote:
> >
> > Stephen,
> >
> > Sorry for the delay in getting back to you on this.
> >
> > A simple form of DELETE request could be something like this:
> >
> >         <element name="DeleteRequest">
> >          <complexType>
> >           <sequence minOccurs="0" maxOccurs="1">
> >             <element name="CredentialSelector" type="string"/>
> >             <element name="LastModified" type="dateTime" maxOccurs="1"/>
> >
> >           </sequence>
> >          </complexType>
> >         </element>
> >
> > I think this would meet the requirements in section 3.3 of the framework:
> >
> > 1. The CredentialSelector identifies the credential to delete.
> > 2. The LastModified is the optional fingerprint.
> >
> > A DELETE-ALL operation could be handled by having an empty request.
> >
> > The references to delete could be removed from the description of the
> > UploadRequest by changing the first six paragraphs of section 2.2.1 as
> > follows:
> >
> > 2.2.1   Credential Upload
> >
> >    This operation REQUIRES mutual authentication.
> >
> >    The purpose of this operation is to allow the client to deposit a
> >    credential with the server.
> >
> >    The client sends an UploadRequest message to the server which can
> >    contain zero or one Credential.
> >
> >    If a credential with the same credential selector field as in the
> >    UploadRequest, (a "matching" credential), already exists for the
> >    account, then that credential is replaced with the new credential
> >    from the UploadRequest. Otherwise a "new" credential is associated
> >    with that account.
> >
> >    If no "matching" credential exists, the server returns an error.
> >
> >
> >
> > A new section would then be needed describing the new operation.
> >
> > 2.2.3 Credential Delete
> >
> >    This operation REQUIRES mutual authentication.
> >
> >    The purpose of this operation is to allow the client to delete one or
> > more credentials
> >    associated with the account.
> >
> >    The client sends an DeleteRequest message to the server which can
> >    contain zero or one CredentialSelector. If the UploadRequest contains no
> >    CredentialSelector then the all the credentials associated with that
> > account
> >    are deleted.
> >
> >    If no "matching" credential exists, the server returns an error.
> >
> >    If the LastModified value is present in the DeleteRequest then it MUST be
> > the value which
> >    was most recently received in a corresponding DownloadResponse for
> >    that credential. If the value does not match then the server MUST NOT
> >    delete the credentials.
> >
> >    The server responds with an error or acknowledgement message.
> >
> > Dale raised the issue of unintentionally deleting all credentials but I'm
> > not sure how much of a risk there is since the PDUs would not be created by
> > the user's directly.
> >
> > > -----Original Message-----
> > > From: Stephen Farrell [mailto:[email protected]]
> > > Sent: 19 December 2002 12:16
> > > To: Richards, Gareth
> > > Cc: [email protected]
> > > Subject: Re: Credential DELETE Operation
> > >
> > >
> > >
> > > Gareth,
> > >
> > > I do have some sympathy with this approach, but its somewhat late
> > > in the day (for this rev of the I-D) to be making such a bigish
> > > change given that we do have a working protocol (I don't think
> > > you're saying it doesn't work as is) and don't have text for
> > > the suggested change.
> > >
> > > So I'd be against making this change right now.
> > >
> > > During the last-call of the protocol draft (next rev
> > > hopefully today!)
> > > you can of course suggest this change *with specific text*
> > > that implements
> > > it (and I'd suggest waiting to base your text on the -05 I-D).
> > >
> > > At that stage we can take it on board or not, depending on the usual
> > > things...
> > >
> > > Is that ok?
> > >
> > > Stephen.
> > >
> > > "Richards, Gareth" wrote:
> > > >
> > > > In the current ID, credentials are deleted using the UploadRequest.
> > > >
> > > > According to section 2.2.1:
> > > >
> > > > a) If the UploadRequest contains no Credential and the UploadRequest
> > > > contains a "Delete="yes"" attribute, then the all the
> > > credentials associated
> > > > with that account are deleted.
> > > >
> > > > b) If the new credential from the UploadRequest contains no
> > > PayLoad field
> > > > and the new credential has a "Delete="yes"" attribute, then
> > > the (one and
> > > > only) "matching" credential is deleted.
> > > >
> > > > One minor point is that in the current schema the Payload
> > > is not an optional
> > > > element in the CredentialType and this appears to be
> > > required to allow the
> > > > second delete to occur.
> > > >
> > > > However, it may be simpler to implement the DELETE
> > > operation described in
> > > > Section 3.3 of the framework document with a separate
> > > DeleteRequest rather
> > > > than overloading the UploadRequest in the way described.
> > > One possibility
> > > > would be for the DeleteRequest PDU to be either empty or contain an
> > > > CredentialSelector and optional LastModified.  If it is
> > > empty then it is a
> > > > request to delete all credential otherwise it is a request
> > > to delete a
> > > > specific credential.
> > > >
> > > > This would have a number of advantages:
> > > >
> > > > 1) There would be no need to have a Delete attribute in the
> > > CredentialType.
> > > >
> > > > 2) There would be no need to have an optional Payload since
> > > the only time a
> > > > Credential can meaningfully not contain a Payload is if the
> > > Delete attribute
> > > > is set to "yes" and it is contained in an UploadRequest.
> > > >
> > > > 3) The UploadRequest PDU could be simplified by removing the Delete
> > > > attribute and making the Credential mandatory.
> > > >
> > > > 4) The conditions on the use UploadRequest given in section
> > > 2.2.1 would be
> > > > simplified.
> > >
> > > --
> > > ____________________________________________________________
> > > 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