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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-jc message

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


Subject: Re: [security-jc] A question: Modeling Provisioning as new SAMLStatements


Darran,

Sounds like a simple transaction system. For this I
tend to think that well known messages rather than
arbitrary XML documents will be the payloads.

Most likely, it will be more efficient to express
these messages in an ASN.1 schema and to encode them
using either canonical XML (cXER) or the Distinguished
Encoding Rules (DER) so that they can be signed and/or
encrypted easily using exactly the same, simple
processing requirements specified today in RSA PKCS#7,
IETF SMIME CMS, X9.84 and OASIS XCBF.

If a high volume of transactions are anticipated, it
may be best to transfer XML instance values in a compact
DER binary format. The sender and receiver will both
still enjoy an XML markup representation of the same
abstract transaction values. But they will not be
stuck with sending the redundant markup tagging
information over and over again for each instance
of a message.

Phil


Phil


Darran Rolls wrote:

> JC
> 
> I would like the JC to consider the flowing: 
> 
> As the PS-TC continues to advance the SPML specification forward, we are debating using the SAML 1.0 framework to carry provisioning requests.  A possible implementation of this could be the development of new SAML <Statement> elements.  Based on the following short précis of SPML's charter, intentions and general model, I ask you to consider the following question.  Does it make sense to implement SPML as a range of extended SAML <Statements> and what would you see as the possible pros & cons of taking this approach?
> 
> SPML in a nutshell
> ------------------
> SPML is intended to be an XML based protocol, schema and transport binding(s) for conveying provisioning requests and receiving provisioning request responses. SPML intends to address batch and a certain degree of transactional semantics around these request flows, such that several requests can be collected together and executed.  SPML implicitly support requesting the creation, deletion, update and listing of accounts and data in these request/response flows. The full charter is available in [1].
> 
> The proposal before the PS-TC is to model these operations as new SAML <Statements>.
> 
> Sample usage scenario for SPML
> ------------------------------
> A Requesting Authority (RA), say a custom application or some other software element, contacts a Provisioning Service Point (PSP), say a vendor supplied provisioning application, and establishes a secure authenticated session.  Based on a defined security and control mechanism (out of scope here), the RA requests the creation (provisioning) of an account on a host/application managed by the PSP.  Relevant security policy, audit and all that good stuff happens (out of scope here) and the PSP creates the account.  When it has finished creating the account, the PSP sends a response message to the RA saying "I'm done with your request". 
> 
> The full use cases are available in [2], but the above is a reasonable enough summary for the purposed of my question.
> 
> Thanks 
> 
> [1] http://www.oasis-open.org/committees/provision/#charter
> [2] http://www.oasis-open.org/committees/provision/docs/draft-spml-use-cases-04.doc
> 
> --------------------------------------------------------
> Darran Rolls                      http://www.waveset.com
> Waveset Technologies Inc          drolls@waveset.com 
> (512) 657 8360                    
> --------------------------------------------------------
> 
> 
> 
> ----------------------------------------------------------------
> 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