You might add:
·
Verification of sender identification includes facility reply,
as well as facility bids for demand and bids for sell (bids should be private
no?) and also for forward demand estimates even if not a bid.
·
Do we need sender ID verification for device/system discovery?
Or maybe that stays at the managed energy level, not collaborative energy?
·
Seems I’ve heard some asking that prices and signals be
private as well, along with I presume receiving system ID verification
David
Thanks, Toby - good link.
On the broader issues of security and model, for EITC I think the issues are
(1) Verifiable identity of sender of messages (grid integrity and prices at
least).
(2) Delegation of authority to receive and act on signals (for aggregators,
flexibility)
(3) Integrity of messages (all)
Others?
BTW, this addresses action item 14 - let's continue this discussion in this
thread.
bill
--
William Cox
Email: wtcox@CoxSoftwareArchitects.com
Web: http://www.CoxSoftwareArchitects.com
+1 862 485 3696 mobile
+1 908 277 3460 fax
Considine, Toby (Campus Services IT) wrote:
Thanks, Bill
Reading standards is soooo much fun. To get a glimpse of where
these fit together, I recommend:
http://self-issued.info/
tc
"A man should never be ashamed to own that he has been in
the wrong, which is but saying ... that he is wiser today than yesterday."
-- Jonathan Swift
From: William Cox [mailto:wtcox@CoxSoftwareArchitects.com]
Sent: Wednesday, October 14, 2009 10:31 AM
To: Energy Interoperation TC
Subject: [energyinterop] Relevant OASIS TC work on security
This is a brief list of links for OASIS work on fine-grained
security that is relevant to the Energy Interoperation TC. This closes action
item 7.
As is common practice in OASIS, a security model (including policies) is
commonly done by a TC doing work such as that being done by the EITC; the
actual security implementation is composed with, e.g., the interoperation
protocol.
This allows for clean substitution and evolution.
Key security standards and TCs:
The security-related TCs in OASIS are at http://www.oasis-open.org/committees/tc_cat.php?cat=security
with descriptions and links. There is a lot of work in key management,
access control, federation, and polity.
WS-Security (OASIS Standard) http://www.oasis-open.org/specs/#wssv1.1
produced by the Web Services Security TC (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss)
Profiles, and a toolkit from which to assemble secure applications.
SAML (Security Access Markup Language) (OASIS Standard) http://www.oasis-open.org/specs/#samlv2.0
produced by the Security Services TC (http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security)
This base standard is broadly adopted and used.
XACML (eXtensible Access Control Markup Language) (OASIS Standard) http://www.oasis-open.org/specs/#xacmlv2.0
produced by the XACML TC ( http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
). A markup language for defining access control.
See also OASIS podcasts and webinars (on http://www.oasis-open.org/events/webinars/
)
XACML Interop Recap http://www.oasis-open.org/events/webinars/OASIS-XACML-InterOp-Recap-Edited.mp3
Architectural Implications for SOA Composition and implications for security (http://www.oasis-open.org/events/webinars/2008-06-20-soa-composition-architectural-alternatives.wmv)
OASIS Security Services (SAML) for Identity Federation (http://www.oasis-open.org/events/webinars/2007-07-13-What-Is-SAML-All-About.wmv
)
OASIS XACML - Fine Grained Access Control - Present and Future (http://www.oasis-open.org/events/webinars/2007-07-12-XACML-Access-Control.wmv
)
bill cox