[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [soa-rm] Identity
Joe - -
For security, I think we can use the
neo-classical "CIAA" set of security "values" (benefits we are seeking from
security measures) as a foundational concept:
confidentiality (info not
disclosed to wrong people)
integrity (info not altered or corrupted or
destroyed)
availability (access not denied to legitimate users)
and
accountability (any view of or change to info is traceable to the responsible
person.) (This is the "neo" part - -we used to say "authentication" but
that's a "tool" not an intrisicic "value".)
To achieve these values we
then enter a discussion of threat sources and technical (or administrative)
countermeasures, like link encryption or PKI or separation of duties. We
translate this security strategy into a set of security policies (and the means
to implement them.)
Does that sound
right?
Martin
________________________________
From:
Chiusano Joseph [mailto:chiusano_joseph@bah.com]
Sent:
Tue 5/10/2005 11:42 AM
To: SOA-RM
Subject: RE: [soa-rm]
Identity
More potential security aspects:
- Policy (noting
that this is already covered in our RM)
- Confidentiality
- Message-Level
Security
- Cross-Domain Trust
Part of the question may be how much if
this is specified in an RM, and how much in a Reference Architecture
(RA)*
Joe
*sneaky attempt to get a response on last evening's
posting on RM vs. RA ;)
Joseph Chiusano
Booz Allen
Hamilton
Visit us online@ http://www.boozallen.com <https://webmail.bah.com/exchweb/bin/redir.asp?URL=http://www.boozallen.com/>
________________________________
From:
Ken Laskey [mailto:klaskey@mitre.org]
Sent: Tue
5/10/2005 11:39 AM
To: SOA-RM
Subject: Re: [soa-rm]
Identity
The essentials are
authentication - I have
confidence I know who you are
authorization - I know who you are and I am
authorize to request things
of you and/or you are authorized to requests
things of me
integrity - other communications are not being
tampered
non-repudiation - neither one of us could later say this exchange
did
not occur
Identity is a part of this but is not sufficient on its
own. Also, it
is not one way because there is often a need for
reciprocity.
Ken
On May 10, 2005, at 11:17 AM, Duane Nickull
wrote:
> What about from the Service providers point of view? I
definitely
> think that identifying service consumers is not required in
all cases,
> however service providers have some form of implied
identity.
>
> The expedia example however does raise the question of
would you use
> the site to book a trip if you could not identify it was
Expedia's
> site? If just before you were going to give them your credit
card, it
> jumped to a different domain name? Identity is
implied by the URL
> resolution process, which in itself places a great
deal of security
> requirements on the entire DNS process.
>
>
I am not thinking so much in terms of a service consumer as I am the
>
service provider. Ajay made the point in his presentation that it
>
would be mandatory to be able to ascertain to some degree that the
>
service you are going to use is the one you want to use.
>
> I would
at least like to mention it in the RM as an aspect (perhaps
> just in
passing). To me, the Service description is probably where a
>
service provider could make a statement of claim regarding their
>
identity and perhaps supply a token, even as simple as a URI, to
> provide
proof.
>
> anyone else?
>
> Duane
>
>
--
> ***********
> Senior Standards Strategist - Adobe Systems, Inc.
-
> http://www.adobe.com
> Chair
- OASIS Service Oriented Architecture Reference Model Technical
>
Committee -
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
>
Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
>
Adobe Enterprise Developer Resources -
> http://www.adobe.com/enterprise/developer/main.html
>
***********
>
>
------------------------------------------------------------------------
------------------
Ken
Laskey
MITRE Corporation, M/S H305 phone:
703-983-7934
7515 Colshire
Drive
fax: 703-983-1379
McLean VA
22102-7508
*** note change of phone extension from 883 to 983 effective
4/15/2005
***
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]