[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Minutes: Security Subteam 10/01/01
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:SPatil@iona.com] |Sent: Monday, October 01, 2001 6:59 PM |To: 'regrep-security@lists.oasis-open.org' |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> |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC