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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

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


Subject: Use Cases and Governance


Kenneth et al,

 

I’ve made a few edits to the Google Use Cases document (now editable by anyone from this link).  I will be making a few more before tomorrow morning’s session, which I’m hoping to dial in for.

 

Regarding the initial discussion we have scheduled on Governance, I’m thinking that the content I added to Use case 24 in particular may be helpful.  I’ve tried to articulate a framework that includes the different models we’ve discussed for trust and governance.  See below for the text of that specific use case, or the link for the full document.

 

Regards,

Roger

 

 

Use case 24

As a service provider I want to verify, before accepting to receive a business document, that the sending party and/or sending party’s service provider has been accredited

 

Description

A Sending Service Provider is attempting to send a document to a Receiving Service Provider, each acting on behalf of their respective Sender and Receiver Parties. Before accepting the document for forwarding to the Receiver, the Receiver Service Provider wishes to validate that document was legitimately sent by the claimed Sender, by:

 

1.       Establishing trust in the Sender Service Provider’s assertions of Sender-delegated authority through a Trust Model, i.e. by either:

a.       A bilateral Trust Agreement between the two Service Providers; or

b.      A Trust Framework, establishing a chain of trust between the Service Providers indirectly, via one of more trust intermediaries; or

c.       A Trust Lookup, that is, Authentication of the Sender Service Provider as such via lookup of a public record the Sender is known to control (e.g. their DNS domain record). This would authenticate the Sender Service Provider as a proxy for Sender (e.g. as the endpoint for the Sender Collaboration Authorization Service).

d.      Explicit Trust, that is Authorization of Sender Service Provider by the Authenticated Sender.

 

2.       POSSIBLY ALSO requiring explicit Authorization by Receiver and/or their Service Provider of Receiver’s Connection with Sender

 

 

Such a Trust or Governance model enables some level of upfront trust between Service Providers claiming to act as proxies or delegates for their respectively users.  The model is defined by the agreement or chain of agreements between the parties, Service Providers, and Trust/Identity Providers. In particular, those agreements should specify that a Service Provider publishing a user identity with associated attributes, such as email or domain:

 

1.       MUST obtain that user’s agreement before publishing such an Identity, and any Attributes/Services associated with it;

2.       MUST, for each such user Identity Attribute:

a.       declare a Trust Level as defined in the Trust Framework Agreements; and

b.      obtain verification or certification by a process conforming with the requirements defined for such a Trust Level (e.g. for “Basic” trust in an email address, by the user clicking a link in a verification email)

3.       MUST act on behalf of that user in accordance with agreed Terms of Service and Privacy Policy, where such Terms of Service and Privacy Policy also conform to any requirements in the Trust Framework Agreements.

 

PEPPOL



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