Yes - really OCCI will not define authorization or anything AAA/IdM but merely expose a way, by extension, to point/discover to such systems at most. -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Wednesday, October 06, 2010 5:08 PM To: Csom Gyula; occi-wg@ogf.org Subject: Re: [occi-wg] Renaming the "Link" base type Hi, Authorization will likely not make it to the first version of OCCI. Authentication will be available though. You are however free to implement "users" as a sub-type of Resource and then use ResourceLink to associate users with resources. regards, Ralf On Wed, 06 Oct 2010 17:01:11 +0200, Csom Gyula <csom@interface.hu> wrote:

Hi,

Do you plan to add authorization support to the protocol? That is will OCCI handle users and ownership information? Just because ownership means a "link" from a resource pointing to a user...

Cheers, Gyula ________________________________________ Feladó: occi-wg-bounces@ogf.org [occi-wg-bounces@ogf.org] ; meghatalmazó: Ralf Nyren [ralf@nyren.net] Küldve: 2010. október 6. 16:33 Címzett: occi-wg@ogf.org Tárgy: [occi-wg] Renaming the "Link" base type

Hi,

It is easy to confuse the OCCI "Link" base type with HTTP "Link Header" and the general term of linking.

Therefore it was proposed during today's conf call to rename the base type "Link" to "ResourceLink". That way we let the name make clear what the Link is used for, i.e. linking Resources.

Would appreciate your comments. Deadline is on Friday.

regards, Ralf

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

Hi Gyula, You hit one of the areas of occi that pushed off to a later version of the specification and a very real issue for the whole of cloud computing. You should join Steve Holcombe's linked in group "data ownership in the cloud". It been a bit dead lately ... Occi's general approach towards ownership and credentials was adopted/inherited from http. The http 1.1 spec supplies a mechanism to initiate authentication requests, transfer authentication credentials and return authentication request responses. It does not provide any approach or mechanism to manage credentials. Authorization is implied to some set of resources residing behind the authenticator gate, where another set of constraints, outside of the http scope, guide any need of additional authentication and authorization. Our requirements for credential management introduces use cases not currently addressed by http specification. Ownership has been a area of interest for several groups over the past few years. Governance, stewardship, custodial practices, and authority are always buzzing around, but little progress is made. Legal issues and the lack of standard practices are high hurdles to clear. Credential management has issues as complex the data ownership. Ownership is governed by negotiated policies, however, local, regional and national mandates impact provider management capabilities. For example, if a set of provider created credentials need to be changed by the consumer, a much different set of capabilities are required than if credentials created then email to the consumer. I've been struggling with proposing an approach for occi. I feel that occi should contain a meta data object that "links" to a credential instantiation and its associated meta data. In the occi domain there may be several actors creating credentials. In cases consumers may share credentials between users accessing a common resource. In other cases, each resource consumer has unique credentials. Consumers may have access to an external resources through a proxy. The proxy may require unique credentials from each consumer. The connection between the proxy and the provider may have a different credential hidden from the consumers. An example of this type of resource is data libraries with a corporate account employees each with their unique credentials proxy though a common gateway with credentials to a data provider. Private clouds can have compute resources with multiple consoles. Each console may have multiple credentials permitting multiple operators access to the console. In this case the occi administrator is supplying the credentials to the occi configuration. Private clouds deployed with third party data services could also follow the user case above. Another private cloud use case involves both authentication credentials and encryption keys to gain access to storage data. The storage resource would require both credentials and a key or key identifier. The more likely scenario is the private cloud management application would maintain the key and automatically send it to the storage during instantiation. That is if its not on a key card. I have a quick breakdown: *Credential Issuance:* (n is multiple credentials) Immutable-ish credentials issued by a provider to the consumer. Pn--->C Credentials issued by the consumer to the provider. Cn--->P Temporary credentials issued by a provider, then changed by the consumer. Pn--->C, [Cn--->P or multiple C--->P] The pattern above can be applied to resources: *Credential Issuance:* (n is multiple credentials) Immutable-ish credentials issued by a Resource creator (occi system) to the consumer. Rn--->C Credentials issued by the consumer to the Resource provision defnition. Cn--->R Temporary credentials issued by a Resource creator (occi system) , then changed by the consumer. Rn--->C, [Cn--->R or multiple C--->R] In practicality, the creating the resource could only issue one credential, the user credentials could be appended later. But, taking a template of the occi system and move it to another provider a serialized process and could be inconvenient, or a time consuming serial activity. Introducing formalized credentials to Resources sort of breaks the network resource model. The network resource is actually to (2) components, a virtual NIC and a gateway. The gateway may need credentials to access it. If the gateway is connected to a VPN (as an external resource), a set of credentials would have to be sent to the VPN endpoint. During initialization, we need a way to communicate authentication results fromm the occi system to the consumer. I'm looking at the oasis kmip specification to help define some key and certificate definition. They support certificates. Home Page: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip Docs: http://www.oasis-open.org/committees/documents.php?wg_abbrev=kmip I'll get the first swag at the section in the extension section tomorrow. After finishing console.. -gary On 10/7/2010 4:48 AM, Csom Gyula wrote:

The challenge is the ownership information. To put it simply: OCCI may lack authz but I think it cannot lack ownership information. That is it must handle identity information during resource creation. I didn't have time to read through authentication, yet. So my question is:

Does OCCI receive identity information on resource creation?

Reason:

(1) Authorization relies on ownership information (besides others), it must link cloud resources and users. Without the knowledge of ownership no authz could ever work.

(2) Question: who will record ownership information? If OCCI does this I have no question. However if it doesnt then the external system must do this.

(3) Question: How will an external system record ownership information? I see 2 basic scenarios (though others might be possible as well):

(a) An external (proxy like) system recieves the create request first which is then forwarded to OCCI. In this case the external system must be OCCI-aware in order to extract ownership information. But can we expect from a generic authz system to do this? I would say no. Generic authz systems are generic not OCCI-specific:)

(b) OCCI receives the create requests first, in this case OCCI must be aware of the identity in order to push ownership information to the authz system.

Hence in either case OCCI must deal with identity/ownership: either record it or pass it through.

Note that this is just a quick analyis:)

Cheers, Gyula ________________________________________ Feladó: Edmonds, AndrewX [andrewx.edmonds@intel.com] Küldve: 2010. október 7. 0:57 Címzett: Ralf Nyren; Csom Gyula; occi-wg@ogf.org Tárgy: RE: [occi-wg] Renaming the "Link" base type

Yes - really OCCI will not define authorization or anything AAA/IdM but merely expose a way, by extension, to point/discover to such systems at most.

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Wednesday, October 06, 2010 5:08 PM To: Csom Gyula; occi-wg@ogf.org Subject: Re: [occi-wg] Renaming the "Link" base type

Hi,

Authorization will likely not make it to the first version of OCCI. Authentication will be available though. You are however free to implement "users" as a sub-type of Resource and then use ResourceLink to associate users with resources.

regards, Ralf

On Wed, 06 Oct 2010 17:01:11 +0200, Csom Gyula<csom@interface.hu> wrote:

...

Hi,

Do you plan to add authorization support to the protocol? That is will OCCI handle users and ownership information? Just because ownership means a "link" from a resource pointing to a user...

Cheers, Gyula ________________________________________ Feladó: occi-wg-bounces@ogf.org [occi-wg-bounces@ogf.org] ; meghatalmazó: Ralf Nyren [ralf@nyren.net] Küldve: 2010. október 6. 16:33 Címzett: occi-wg@ogf.org Tárgy: [occi-wg] Renaming the "Link" base type

Hi,

It is easy to confuse the OCCI "Link" base type with HTTP "Link Header" and the general term of linking.

Therefore it was proposed during today's conf call to rename the base type "Link" to "ResourceLink". That way we let the name make clear what the Link is used for, i.e. linking Resources.

Would appreciate your comments. Deadline is on Friday.

regards, Ralf

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

---

occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

I'd agree with what Alex positions - we still have a namespace (be it explicit or implicit) that is OCCI. Link is still good with me. If people get confused with HTTP Link and OCCI Link then perhaps they're reading the wrong spec! :-p -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of alexander.papaspyrou@tu-dortmund.de Sent: Wednesday, October 06, 2010 6:33 PM To: ralf@nyren.net Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Renaming the "Link" base type I'd vote for keeping "Link". Core should be clean, and not tailored to some naming in the renderings. I know that, for HTTP, certain things are fix, but I don't see such a danger for confusions, anyway. -Alexander Am 06.10.2010 um 16:33 schrieb Ralf Nyren:

Hi,

It is easy to confuse the OCCI "Link" base type with HTTP "Link Header" and the general term of linking.

Therefore it was proposed during today's conf call to rename the base type "Link" to "ResourceLink". That way we let the name make clear what the Link is used for, i.e. linking Resources.

Would appreciate your comments. Deadline is on Friday.

regards, Ralf

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

In that case those (incl myself possibly) acting as editor need to qualify and scope all mentions of HTTP-Link via canonical reference. Andy On 7 Oct 2010, at 11:31, "Ralf Nyren" <ralf@nyren.net> wrote:

As long as all parts of the spec are crystal clear on whether it is Link base type, HTTP Link Header, etc that is referred to I am fine with any name :-D

Let's say I have had to point out the importance of the distinction more than once... ;)

regards, Ralf

On Thu, 07 Oct 2010 00:57:04 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:

...

I'd agree with what Alex positions - we still have a namespace (be it explicit or implicit) that is OCCI. Link is still good with me. If people get confused with HTTP Link and OCCI Link then perhaps they're reading the wrong spec! :-p

-----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of alexander.papaspyrou@tu-dortmund.de Sent: Wednesday, October 06, 2010 6:33 PM To: ralf@nyren.net Cc: occi-wg@ogf.org Subject: Re: [occi-wg] Renaming the "Link" base type

I'd vote for keeping "Link". Core should be clean, and not tailored to some naming in the renderings. I know that, for HTTP, certain things are fix, but I don't see such a danger for confusions, anyway.

-Alexander

Am 06.10.2010 um 16:33 schrieb Ralf Nyren:

...

Hi,

It is easy to confuse the OCCI "Link" base type with HTTP "Link Header" and the general term of linking.

Therefore it was proposed during today's conf call to rename the base type "Link" to "ResourceLink". That way we let the name make clear what the Link is used for, i.e. linking Resources.

Would appreciate your comments. Deadline is on Friday.

regards, Ralf

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg

_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg