[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Credential DELETE Operation

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
>