Guys,
ACL would be a very appealing feature for private registries, even for
public registries. Controlling visibility based on roles would be a big win
for ebXML registry.
just my 2c
cheers
|-----Original Message-----
|From: Patil, Sanjay [mailto:]
|Sent: Monday, October 01, 2001 6:59 PM
|To: ''
|Subject: Minutes: Security Subteam 10/01/01
|
|
|
|
|Attendees:
| Suresh Damodaran
| Farrukh Najmi
| Sekhar Vajjhala
| Sanjay Patil
|
|- Message Signature
| Is it required at this point of time to consider supporting or
|leaving the
| specification forward compatible for digital signature
|technologies other
|than
| XML Signature? Specially, does the scenario of thin Vs. fat Registry
|Client
| brings forth any such requirements?
| Resolution: For the purposes of V2, it would be sufficient to say -
| The V2 spec requires compliance with XML Signature specification for
| message signatures. In future versions, other digital signature related
| specifications might be brought into picture, however for V2,
|the Registry
| behavior is undefined if specifications other than XML Signature are
| used for message signing.
|
|- Packaging of Signature and Content
| Three alternatives were considered.
| a> Content and Signature are separate parts, with
|identification of each
| part and the blob that is signed handled by Content-Type and
|Content-URI
| MIME headers
| b> Content and Signature are separate MIME parts. The MIME
|type being used
| is multipart/related. The order of MIME parts and probably
|Content-Type
| to be used for identifying Signature from Content. Any
|other details
|essential
| for Signature to identify the blob in the content that is
|signed, etc
|are to
| be clearly specified in the V2 spec.
| c> Make use of Multipart/Signed type, register a new MIME type for XML
|Signature
| (RFC 1847)
|
| Resolution: Using Multipart/Signed will require more than general-MIME
|infrastructure.
| In order to keep low barrier of entry, handling of
|Multipart/related
|which is handled
| by general-MIME infrastructure is preferred.
| Assumption: All messages are required to be signed. Otherwise,
|differentiating
| between signed and unsigned Multipart/related introduces
|complexity in specification
| and thereby implementations.
|
|- Access Control Policies
| Suresh presented and walked the attendees through a first cut of ACL
|support proposal.
| After discussion and exploring several possibilities for
|minimum support
|for ACL, it was
| considered to either postpone or phase out work on ACL in order to meet
|specification
| deadlines.
|
|thanks,
|Sanjay Patil
|-----------------------------------------------------------------
|-----------
|------------------------------
|IONA
|Total Business Integration (TM)
|Phone: 408 350 9619 http://www.iona.com
|
|
|----------------------------------------------------------------
|To subscribe or unsubscribe from this elist use the subscription
|manager: <http://lists.oasis-open.org/ob/adm.pl>
|
