[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Credential DELETE Operation
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:stephen.farrell@xxxxxxxxxxxx]
> > Sent: 19 December 2002 12:16
> > To: Richards, Gareth
> > Cc: ietf-sacred@xxxxxxx
> > 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:stephen.farrell@xxxxxxxxxxxx
> > 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:stephen.farrell@xxxxxxxxxxxx
Ireland http://www.baltimore.com