[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Credential DELETE Operation

To: "'stephen.farrell@xxxxxxxxxxxx'" <stephen.farrell@xxxxxxxxxxxx>
Subject: RE: Credential DELETE Operation
From: "Richards, Gareth" <GRichards@xxxxxxxxxxxxxxx>
Date: Fri, 7 Feb 2003 14:38:39 -0000
Cc: ietf-sacred@xxxxxxx
List-archive: <http://www.imc.org/ietf-sacred/mail-archive/>
List-id: <ietf-sacred.imc.org>
List-unsubscribe: <mailto:ietf-sacred-request@imc.org?body=unsubscribe>
Sender: owner-ietf-sacred@xxxxxxxxxxxx
Stephen,

Maybe a DeleteRequest with an explicit delete-all could be like this.


  <element name="DeleteRequest">
    <complexType>
      <sequence>
        <choice>
          <sequence>
            <element name="CredentialSelector" type="string"/>
            <element name="LastModified" type="dateTime" minOccurs="0"/>
          </sequence>
          <element name="All"/>
        </choice>
        <element ref="sacred:ProcessInfo" minOccurs="0"/>
      </sequence>
    </complexType>
  </element>
  
What I have tried to do is to make it so that a delete-all is not
syntactically legal if it contains a CredentialSelector.

A delete-all would be a DeleteRequest with an <All> element and an optional
ProcessInfo.

A normal delete would be a DeleteRequest with a CredentialSelector and
optional LastModified and ProcessInfo elements.

A new section could then be as follows.

2.2.3 Credential Delete
    
   This operation REQUIRES mutual authentication. 
    
   The purpose of this operation is to allow the client to delete one or
   all credentials associated with the account. 
    
   The client sends an DeleteRequest message to the server which can 
   contain either a CredentialSelector or an All element. 

   If the DeleteRequest contains an All element then the all the 
   credentials associated with that account are deleted.  

   If the DeleteRequest contains a CredentialSelector then the request 
   MAY include a LastModified value.  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.

   If no "matching" credential exists, the server returns an error.     

   The server responds to this request with an error or acknowledgement 
   message.   

> 
> 
> If we adopt the new message, that'd make more sense.
> 
> What about making delete-all explicit? I assume you'd agree with
> that too? How'd you want that done?
> 
> Stephen.
> 
> "Richards, Gareth" wrote:
> > 
> > Stephen,
> > 
> > >
> > > 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?
> > 
> > I would think that if we do have a DeleteRequest then there 
> is no need to
> > allow an empty UploadRequest and so the start of section 
> 2.2.1 could be:
> > 
> > 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 MUST
> > contain one Credential.
> > 
> > The schema could then be:
> > 
> >         <!-- Upload request -->
> >         <element name="UploadRequest">
> >          <complexType>
> >           <sequence>
> >            <element name="Credential" type="sacred:CredentialType"/>
> >           </sequence>
> >          </complexType>
> >         </element>
> > >
> > > 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
> > >
> 
> -- 
> ____________________________________________________________
> 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
>
Prev by Date: RE: Credential DELETE Operation
Next by Date: Re: WG Last Call [Was: I-D ACTION:draft-ietf-sacred-protocol-bss-06.txt]
Previous by thread: RE: Credential DELETE Operation
Next by thread: I-D ACTION:draft-ietf-sacred-protocol-bss-05.txt
Index(es):
- Date
- Thread