OASIS Specification Template s11

Identity in the Cloud TC – Inter-Cloud Use Case Version 0.2

1.1 Use Case Inter-Cloud Document Exchange – Number: ##

1.1.1 Description / User Story The ‘Inter-Cloud’ is a term being used by Cisco’s CTO Padmasree Warrior, and Internet creator (and Google Chief Internet Evangelist) Vint Cerf, among others. Cerf says the Inter-Cloud represents a “new layer of the Internet architecture”. The Inter-Cloud encompasses many different use cases, including VM mobility; however, data and process interoperability between cloud APIs is acknowledged to be the “simpler use case” (Cisco), that “may constitute the beginning of an inter-cloud computing language” (Cerf). Historically, simple email interoperability between AOL, Compuserve etc based on standards in 1995 triggered the Internet wave (followed by the Web). The same pattern may be recurring now with data/process interoperability between leading business app/service “clouds” as the leading Inter-Cloud use case. Even in this simpler Inter-Cloud use case (as well as all others), issues of identity are central and unavoidable.

Inter-Cloud Business Document Exchange is a more specific leading use case, within the broader notion of Inter-Cloud Data/Process Interoperability. Two convergent use cases arise: 1) The “Four-corner”: the so-called model based explicitly on exchange between two clouds (i.e. service providers) or systems, each acting as a proxy for one party to a business relationship. Such a model has been established by the pan-European PEPPOL project in Europe, and defined in a normalized fashion under certain ebXML standards. Regarding identity and trust, however, no model beyond peer-to-peer trust arrangements and document signature has been defined. 2) “Three-corner”: a term used for the more prevalent current model whereby each cloud (e.g. a supplier network) requires both buyer and seller parties to have an identity on their system. This becomes problematic, for suppliers in particular, who may need to establish identities on many different clouds to connect with their various customers (i.e. to send documents, or set up routing for documents or payments to be sent to them). New cloud service providers offer to act as a single proxy for suppliers in connecting with the various cloud systems their customers use. However, existing connectivity models only apply once an identity and routing have been established. No standard model has been established for the use of existing identity standards in this context (notably, SAML, OAuth, and OpenID).

In both cases, though in different forms, the use case steps include: i) Establishing a new identity on Party A’s Cloud B (for Party D OR their existing proxy Cloud C) ii) Binding of that new identity (or an existing identity) to the second, related identity (Party D or Cloud C, as appropriate), in order to enable: a. Inter-Cloud interactions on the Parties’ behalf, possibly unattended b. Single-sign-On, to provide seamless user experiences across Cloud B and Cloud C iii) Submission and authentication of documents sent between the Clouds

OASIS ID Cloud – Use Case Template 2011-01-10 Page 1 of 7 Copyright © OASIS® 2011. All Rights Reserved. 1.1.2 Goal or Desired Outcome Goals and intended outcomes of this effort would be: 1. A standard framework for describing current real-world behaviors and new standards regarding document exchange, and facilitating the discovery of ways to automatically set up end-to-end, Inter-Cloud connections between particular endpoint pairs with zero or minimal user intervention. Where such automatic connection set up is not possible, the framework should help cloud providers identify modest, incremental, standards-based changes to facilitate such connectivity. 2. In particular, the framework should define standard ways for binding cloud identities and identity providers to foundational Internet identity standards (email addresses and domain names). 3. Implementation of such standard models by leading cloud service providers (ideally, by their participation in this standardization effort). In particular, the providers participating should ideally include the leading actors and notable services listed below.

1.1.3 Notable Categorizations and Aspects

Categories Covered: Applicable Deployment and Service Models:  Infrastructure Trust Establishment  Cloud Deployment Models  General Identity Management (IM) ○ Private ○ Infrastructure Identity ○ Public Management (IIM) ○ Community ○ Federated Identity Management ○ Hybrid (FIM)  Service Models  Authentication ○ Software-as-a-Service (SaaS) ○ Single Sign-On (SSO) ○ Platform-as-a-Service (PaaS)  Authorization ○ Infrastructure-as-a-Service (IaaS)  Account and Attribute Management ○ Integration-as-a-Service ○ Account and Attribute Provisioning ○ Other (i.e. other “as-a-Service” Models)  Security Tokens  Audit and Compliance

Actors: Systems:  B2B / supplier / e-invoicing networks  ???  Accounting/ERP providers, or cloud proxies, both enterprise and SMB  Payment networks and banks  ? Internet domain registrars and/or hosting providers  ? Internet email providers

Notable Services:  Oracle, SAP, Ariba, IBM, Intuit, Paypal, Microsoft; possibly Cisco, GXS, Google, CA, Sage, HP, US Government, PEPPOL, NACHA, The Clearing House, JPMC, Wells Fargo, Bank of America

Dependencies:  ## TBD

Assumptions:  ## TBD

OASIS ID Cloud – Use Case Template 2011-01-10 Page 2 of 7 Copyright © OASIS® 2011. All Rights Reserved. OASIS ID Cloud – Use Case Template 2011-01-10 Page 3 of 7 Copyright © OASIS® 2011. All Rights Reserved. 1.1.4 Process Flow

1.1.4.1 Partner Identity Provisioning 1. A Cloud T, acting as a proxy for a Supplier S, wants to electronically deliver an invoice to Enterprise E, a customer of S, via E’s designated proxy, Cloud A. This is the first such document to be delivered from S to any recipient via Cloud A. To accept an e-invoice submission from S, in general, Cloud A requires that S first establish an identity with it. Cloud A trusts Cloud T to create such identities on behalf of T’s users such as S. 2. Cloud T has accessed Identity Metadata for Enterprise E that define details of the service Cloud A offers as E’s proxy for provisioning new supplier identities, and/or determining if an existing identity on A for a supplier already exists. 3. The Identity Metadata for Enterprise E specifies whether or not a supplier identity on Cloud A is required to send a document to E. If so, it specifies how to access the Identity Provisioning Service, what identity attributes of Supplier S are supported, and whether they are required or optional, e.g. a. Entity identifier(s), e.g. Domain, DUNS, GLN, Phone, TaxID b. Admin user email address c. Entity and user names d. Supported services, with format and addressing/routing information, e.g. i. Notifications, such as invoice status, remittance detail, orders ii. Payments 4. Error cases may arise if an identity for Supplier S already exists on Cloud A. The handling of such errors, and binding to an existing identity, is addressed a separate use case (Partner Cloud Proxy Setup – Security Token Exchange).

1.1.4.2 Partner Relationship Authorization 1. A Cloud T, acting as a proxy for a Supplier S, wants to electronically deliver an invoice to Enterprise E, a customer of S, via E’s designated proxy, Cloud A. Cloud T has already established a new identity (or bound to an existing identity) on Cloud A for Supplier S. 2. The Identity Metadata for Enterprise E specifies whether or not authorization is required to send documents to E via Cloud A (i.e. to access that messaging channel on Cloud A), via the one-time setup on Cloud A of a trading relationship between E and S. If so, and if a Relationship Authorization Service exists, it specifies how to access it, and what identity attributes of Supplier S are required for authorization to be granted and the relationship on Cloud A established. 3. Cloud A processes the Relationship Setup Request for approval or rejection, by comparison of request details with E’s supplier database, either: i. Automatically and synchronously, by accessing a service to search E’s suppliers (whether stored on A, at E, or some outsourced third party supplier registry); ii. Automatically and asynchronously, by forwarding the request message for processing within E’s ERP system; or iii. Manually, by routing of the request message to a human user. 4. Cloud A generates, or receives, Enterprise E’s response to the Relationship Setup Request Message, and passes it back to Cloud T, acting as proxy for Supplier S.

OASIS ID Cloud – Use Case Template 2011-01-10 Page 4 of 7 Copyright © OASIS® 2011. All Rights Reserved. 1.1.4.3 Partner Addressing/Routing Setup (Attribute Management) 1. A Cloud T, acting as a proxy for a Supplier S, wants to be able to receive documents, and potentially payments, from Enterprise E, a customer of S, via E’s designated proxy, Cloud A. Such documents or payments might be in response to a document S sent (e.g. invoice/payment status, payment plus remittance advice), or initiated by E (e.g. orders). 2. Cloud T wants to ensure that the addressing/routing information for S that is stored in Cloud A (and thereby synchronized as needed with E’s systems) is added or updated as required for all business processes. In particular, T wants to ensure that machine-readable messages relating to automated or integrated processes are routed appropriately. Such addressing/routing information may vary by business process. For a given business process, multiple alternate addressing/routing records for S may exist. The routing of a given document or payment may also depend on document content and business rules (e.g. to ensure that a payment and remittance information are sent back via the return channels specified in the corresponding invoice, for correct payment application). 3. All parties want to ensure that processes for changing such routing information – especially for payments – are secure. (Special requirements may apply for payment versus document routing). 4. Cloud T updates a Metadata/Attributes Record for Supplier S defining changed or additional addressing/routing information pertaining to certain supported business processes. 5. Cloud T triggers propagation of that updated Metadata/Attributes Record to Enterprise E via Cloud A via one of the following channels: a. Direct posting of a cloud-to-cloud update via an Attribute Update Service on Cloud A; b. Publishing the update to Cloud A (and possibly others) via a cloud-to-cloud Publish/Subscribe peering relationship (which might be established for Supplier S only, or for other entities more broadly) c. Propagating the update to Cloud A via an “Inter-Cloud Backbone”, i.e. a peering mechanism between Metadata Registries.

1.1.4.4 Partner Cloud Proxy Setup (Security Token Exchange) 1. A Cloud T, acting as a proxy for a Supplier S, wants to electronically deliver an invoice to Enterprise E, a customer of S, via E’s designated proxy, Cloud A. An identity for Supplier S on Cloud A had previously been established, by some means other than through Cloud T. 2. Cloud T may have attempted to provision a new identity for Supplier S on Cloud A, but had been refused, because of an existing identity. 3. The Identity Metadata for Enterprise E specifies whether or not any service or automated mechanism exists for establishing Cloud T as a proxy for Supplier S on Cloud A, and exchanging security tokens. Such mechanisms might include: a. Entry of Authentication Credentials for the existing identity for S, by a User U who either knows these credentials, or requests them out-of-band; b. Triggering an ‘Access Request’ message to the administrator of the existing identity, requesting access for Cloud T; or c. Provisioning of a new user identity for User U, and requesting authorization and access permissions from the administrator of the existing identity. 4. Cloud T receives approval for access, and the corresponding security tokens, either within a single session for User U, or subsequently, after approval of the request.

OASIS ID Cloud – Use Case Template 2011-01-10 Page 5 of 7 Copyright © OASIS® 2011. All Rights Reserved. 1.1.4.5 Cloud-to-Cloud Authentication and Authorization 1. A Cloud T, acting as a proxy for a Supplier S, wants to electronically deliver an invoice to Enterprise E, a customer of S, via E’s designated proxy, Cloud A. This is the first such document to be delivered from S to any recipient via Cloud A. Cloud A requires an identity for S to send an invoice, and offers an Identity Provisioning Service; to access that service however, Cloud T must be authenticated and authorized to act as a proxy for S for Identity Provisioning. 2. Cloud A may establish that Cloud T is authorized to act as a proxy for Supplier S either by: a. A “Trusted Cloud” agreement between Clouds A and T b. Looking up Identity Metadata for S in a public registry record known to be controlled by S (e.g. a DNS record) to validate that T is indeed legitimately acting as a proxy for S.

Revision Date Editor Changes Made 0.1 January 10, Matt Rutkowski, IBM Initial template draft 2011 0.11 March 24, Roger Bass, Traxian Initial Inter-Cloud use case draft 2011 0.2 April 6, 2011 Roger Bass, Traxian Reorganized into separate, granular use cases [Rev number] [Rev Date] [Modified By] [Summary of Changes]