CloudTrust Protocol (CTP) and A6 API
4 views
Skip to first unread message
Doug
Nov 17, 2009, 6:04:47 PM11/17/09
to A6 (Audit, Assertion, Assessment, and Assurance API) Working Group
Greetings A6 Group,
I'd like to kickoff a discussion of some specifics of the
communication protocol to be used.
Here at CSC, we are developing a Trusted Cloud service offering that
provides the customer with visibilty into the cloud. (Exactly what all
of you have a keen interest in :^) Please see Ron Knode's paper
(Digital Trust in the Cloud) in the file section, as well as my power
point preso (CloudTrust Review A6) discussing the same.
I think we all agree a RESTful web service (or web API) will be
required. Implying a uniform interface:
- Identification of resources
- Manipulation of resources
- Self-descriptive messages
Do we need all HTTP methods? Current CTP HTTP methods: (GET, PUT, POST
and DELETE)
Do any of you have a specific protocol defined to ride on HTTP?
Currently CSC is using the Atom Syndication Format [RFC 4287], but I
feel we may eventually require development of a modified version of
Atom.
Thoughts?
I'd like to kickoff a discussion of some specifics of the
communication protocol to be used.
Here at CSC, we are developing a Trusted Cloud service offering that
provides the customer with visibilty into the cloud. (Exactly what all
of you have a keen interest in :^) Please see Ron Knode's paper
(Digital Trust in the Cloud) in the file section, as well as my power
point preso (CloudTrust Review A6) discussing the same.
I think we all agree a RESTful web service (or web API) will be
required. Implying a uniform interface:
- Identification of resources
- Manipulation of resources
- Self-descriptive messages
Do we need all HTTP methods? Current CTP HTTP methods: (GET, PUT, POST
and DELETE)
Do any of you have a specific protocol defined to ride on HTTP?
Currently CSC is using the Atom Syndication Format [RFC 4287], but I
feel we may eventually require development of a modified version of
Atom.
Thoughts?
Ramkaran
Nov 24, 2009, 2:57:03 PM11/24/09
to A6 (Audit, Assertion, Assessment, and Assurance API) Working Group
I think riding on a SAML like assertion approach makes sense before
the RESTful conversation.
Ramkaran
ramkaran....@sifycorp.com
the RESTful conversation.
Ramkaran
ramkaran....@sifycorp.com
Joe Stein
Nov 24, 2009, 5:14:17 PM11/24/09
to a6...@googlegroups.com, A6 (Audit, Assertion, Assessment, and Assurance API) Working Group
OAuth for programmatic access. This is pretty standard now thanks to
mashups and social networking.
SAML for user federation if a ui emerges
/*
Joe Stein
http://www.linkedin.com/in/charmalloc
*/
mashups and social networking.
SAML for user federation if a ui emerges
/*
Joe Stein
http://www.linkedin.com/in/charmalloc
*/
Gilad Parann-Nissany
Nov 25, 2009, 3:42:23 AM11/25/09
to a6...@googlegroups.com
Sorry if this question is naive.
I was under the impression the main goal was to facilitate "publishing" the capabilities of cloud X, and this seems to imply anonymous queries are welcome and encouraged.
Where exactly do SAML or OAuth come into the picture? What am I missing please?
Regards
Gilad
__________________
Gilad Parann-Nissany
CEO, Founder
http://www.porticor.com/
I was under the impression the main goal was to facilitate "publishing" the capabilities of cloud X, and this seems to imply anonymous queries are welcome and encouraged.
Where exactly do SAML or OAuth come into the picture? What am I missing please?
Regards
Gilad
__________________
Gilad Parann-Nissany
CEO, Founder
http://www.porticor.com/
Hoff
Nov 25, 2009, 7:56:21 AM11/25/09
to A6 (Audit, Assertion, Assessment, and Assurance API) Working Group
While your question may be directed at CTP, I'll suggest that neither
CTP or A6 is about "publishing" the capabilities of a CSP.
Neither are a service registry, although they may need to be aware of
such functionality. The consumer of said intelligence from
a CSP via A6 or CTP may need to directly query the CSP for
capabilities as well as configuration, compensating controls, etc.
Further, *most* (if not all) "anonymous queries" are not welcomed; any
request to a CSP for validation of a sensitive validation, assurance,
audit, etc.
information must be authenticated and authorized, hence the discussion
of SAML and OAuth.
/Hoff
On Nov 25, 3:42 am, Gilad Parann-Nissany <gi...@parann.net> wrote:
> Sorry if this question is naive.
>
> I was under the impression the main goal was to facilitate "publishing" the
> capabilities of cloud X, and this seems to imply anonymous queries are
> welcome and encouraged.
>
> Where exactly do SAML or OAuth come into the picture? What am I missing
> please?
>
> Regards
> Gilad
> __________________
> Gilad Parann-Nissany
> CEO, Founderhttp://www.porticor.com/
CTP or A6 is about "publishing" the capabilities of a CSP.
Neither are a service registry, although they may need to be aware of
such functionality. The consumer of said intelligence from
a CSP via A6 or CTP may need to directly query the CSP for
capabilities as well as configuration, compensating controls, etc.
Further, *most* (if not all) "anonymous queries" are not welcomed; any
request to a CSP for validation of a sensitive validation, assurance,
audit, etc.
information must be authenticated and authorized, hence the discussion
of SAML and OAuth.
/Hoff
On Nov 25, 3:42 am, Gilad Parann-Nissany <gi...@parann.net> wrote:
> Sorry if this question is naive.
>
> I was under the impression the main goal was to facilitate "publishing" the
> capabilities of cloud X, and this seems to imply anonymous queries are
> welcome and encouraged.
>
> Where exactly do SAML or OAuth come into the picture? What am I missing
> please?
>
> Regards
> Gilad
> __________________
> Gilad Parann-Nissany
>
> On Wed, Nov 25, 2009 at 00:14, Joe Stein <crypt...@gmail.com> wrote:
> > OAuth for programmatic access. This is pretty standard now thanks to
> > mashups and social networking.
>
> > SAML for user federation if a ui emerges
>
> > /*
> > Joe Stein
> >http://www.linkedin.com/in/charmalloc
> > */
>
> On Wed, Nov 25, 2009 at 00:14, Joe Stein <crypt...@gmail.com> wrote:
> > OAuth for programmatic access. This is pretty standard now thanks to
> > mashups and social networking.
>
> > SAML for user federation if a ui emerges
>
> > /*
> > Joe Stein
> >http://www.linkedin.com/in/charmalloc
> > */
>
> > On Nov 24, 2009, at 2:57 PM, Ramkaran <ram.ka...@gmail.com> wrote:
>
> > I think riding on a SAML like assertion approach makes sense before
> >> the RESTful conversation.
>
> >> Ramkaran
> >> ramkaran.rudrava...@sifycorp.com
>
> > I think riding on a SAML like assertion approach makes sense before
> >> the RESTful conversation.
>
> >> Ramkaran
Gilad Parann-Nissany
Nov 25, 2009, 11:53:35 AM11/25/09
to a6...@googlegroups.com
Thanks for the clear answer. So we're saying that anyone wanting to take advantage of A6 at provider "X" must register with provider "X" or with someone trusted by "X" ? That would seem necessary of OAuth or SAML are to function.
That can be a fine model; I am just trying to make sure I got it.
That can be a fine model; I am just trying to make sure I got it.
Hoff
Nov 25, 2009, 1:38:14 PM11/25/09
to A6 (Audit, Assertion, Assessment, and Assurance API) Working Group
I'd further clarify the notion of having to "register" with a provider
to suggest that you're
either direcly a customer of Provider X or an authorized third party
duly acting in their proxy
(such as an auditor or third party service provider)
Help?
/Hoff
On Nov 25, 11:53 am, Gilad Parann-Nissany <gi...@parann.net> wrote:
> Thanks for the clear answer. So we're saying that anyone wanting to take
> advantage of A6 at provider "X" must register with provider "X" or with
> someone trusted by "X" ? That would seem necessary of OAuth or SAML are to
> function.
>
> That can be a fine model; I am just trying to make sure I got it.
>
> Regards
> Gilad
> __________________
> Gilad Parann-Nissany
> CEO, Founderhttp://www.porticor.com/
to suggest that you're
either direcly a customer of Provider X or an authorized third party
duly acting in their proxy
(such as an auditor or third party service provider)
Help?
/Hoff
On Nov 25, 11:53 am, Gilad Parann-Nissany <gi...@parann.net> wrote:
> Thanks for the clear answer. So we're saying that anyone wanting to take
> advantage of A6 at provider "X" must register with provider "X" or with
> someone trusted by "X" ? That would seem necessary of OAuth or SAML are to
> function.
>
> That can be a fine model; I am just trying to make sure I got it.
>
> Regards
> Gilad
> __________________
> Gilad Parann-Nissany
Andy@csoandy
Nov 25, 2009, 2:36:13 PM11/25/09
to a6...@googlegroups.com, A6 (Audit, Assertion, Assessment, and Assurance API) Working Group
Provider X should provide an account management interface to permit
their customers to register API agents. Customer responsibility to
mange the accounts; Provider should just provide capabilities.
their customers to register API agents. Customer responsibility to
mange the accounts; Provider should just provide capabilities.
Gilad Parann-Nissany
Nov 25, 2009, 3:16:24 PM11/25/09
to a6...@googlegroups.com
Yes begins to make sense and also defines a practical role for neutral parties like this A6WG as one of many possible authorized 3rd parties. Thanks.
Hoff
Nov 25, 2009, 7:01:16 PM11/25/09
to A6 (Audit, Assertion, Assessment, and Assurance API) Working Group
Yes, that's what I meant when I said "...or an authorized third party
them all" approach that many
IaaS vendors (as an example) have today...one of the things we have to
discuss.
/Hoff
On Nov 25, 2:36 pm, "Andy@csoandy" <a...@csoandy.com> wrote:
> Provider X should provide an account management interface to permit
> their customers to register API agents. Customer responsibility to
> mange the accounts; Provider should just provide capabilities.
>
duly acting in their proxy"
In many cases this will be very difficult given the "one key to rule
them all" approach that many
IaaS vendors (as an example) have today...one of the things we have to
discuss.
/Hoff
On Nov 25, 2:36 pm, "Andy@csoandy" <a...@csoandy.com> wrote:
> Provider X should provide an account management interface to permit
> their customers to register API agents. Customer responsibility to
> mange the accounts; Provider should just provide capabilities.
>
John Menerick
Nov 30, 2009, 12:01:13 AM11/30/09
to a6...@googlegroups.com
I'm hesitant against OAuth due to OAuth's inherent insecurity.
John Menerick
John Menerick
Gilad Parann-Nissany
Dec 1, 2009, 5:17:35 AM12/1/09
to a6...@googlegroups.com
@John Menerick
"inherent insecurity" for solving which problem? OAuth comes down to a way of signing a message. Depending in the problem domain, it can be a decent solution or (I agree) not a decent solution. Could you elaborate?
"inherent insecurity" for solving which problem? OAuth comes down to a way of signing a message. Depending in the problem domain, it can be a decent solution or (I agree) not a decent solution. Could you elaborate?
Reply all
Reply to author
Forward
0 new messages