OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [wsrp][security] minutes from 4.3 telecon


comments below tagged <mc>

-----Original Message-----
From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com]
Sent: Sunday, April 07, 2002 7:21 AM
To: Cassidy, Mark
Cc: 'wsrp@lists.oasis-open.org'
Subject: Re: [wsrp][security] minutes from 4.3 telecon




Mark,

here are some more thoughts about the "security life cycle":

Establish Business Relation
-------------------------------

0. In order to prepare for the following steps to be executed automatically
on the technical level and obtain a credential to be used in step 1. below,
the owner of a consumer may for example contact the owner of the producer,
sign a contract and as a result obtain a customer number and password (low
security) or a customer number and digital certificate (high security). For
free services, no credential at all might be required.

Establish (technical) Trust Relation
----------------------------------------

Pre: - The consumer and the producer are not bound, no trust relation
exists -

1. The consumer sends a message to the producer indicating that it wants to
start using the service (bind operation).

Depending on the required level of security and trust, the consumer's
message may contain:
- No credential
- others inbetween ?
- an SSL client certificate and signature
<mc> I'm assuming credentials passed would be those obtained in step 0
above.  </mc> 

2. The producer receives the first request from the consumer with the
contaned credential in the bind operation

The producer determines whether the credential(s) provided by the consumer
are sufficient. If yes, the producer assigns a consumer ID and sends it
back to the consumer for later reference. Otherwise it indicates that
credentials are missing and information on how/where to obtain these
credentials (see 0).

3. The consumer persistently stores the assigned consumer ID and uses it in
all subsequent requests to the producer from which it was obtained. The
consumer may not share the consumer ID with others.

Post: - The consumer and producer are bound, the consumer is known to the
producer under the consumer ID -

Operation
---------

Pre: - The consumer and producer are bound, the consumer is known to the
producer under the consumer ID -

4. Using the consumer ID, the consumer can use the producer's service(s).
The producer may use the consumer ID for access control, to manage
instances, for logging for auditing porposes,  or to do billing.
<mc> Are you thinking of ID as a sort of security token here?  While ID
would be private between producer & consumer, it may not provide adequate
security on its own.  In the case where some credentials are required to get
the ID in the first place, these credentials may need to accompany each
service request.  </mc> 

Post: - The consumer and producer are bound, the consumer is known to the
producer under the consumer ID -

Destroy (technical) Trust Relation
--------------------------------------

Pre: - The consumer and producer are bound, the consumer is known to the
producer under the consumer ID -

5. a) The consumer terminates the relation with the producer by invoking an
unbind operation providing its consumer ID and discarding the consumer ID
        -> the producer discards all persistent and transient state
associated with the consumer's ID

5. b) The producer terminates the relation with the consumer, e.g. by
        - blocking access for the consumer's ID (allowing for later
reactivation)
        - discarding the consumer's ID and all associated persistent or
transient state (final termination of relation)

Post: - The consumer and the producer do not have a relation, no trust
relation exists -

The two primary types of credentials that come to mind are
- Public Key Certificates (which may be used in SSL/TLS client
authentication to the service with existing infrastructure)
- others inbetween ?
- Something like customer numbers in combination with a password (which may
securely be used in connections protected through SSL/TLS connections
established with server authentication)

Best regards,

Thomas



"Cassidy, Mark" <mcassidy@Netegrity.com> on 04/05/2002 04:51:47 AM

Please respond to "Cassidy, Mark" <mcassidy@Netegrity.com>

To:    "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org>
cc:
Subject:    [wsrp][security] minutes from 4.3 telecon



Attached are the minutes from the 4.3 telecon.  Those on the call, let me
know if any corrections are needed.

Mark.

 <<wsrp security minutes.4.3.htm>>






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC