Review-sheet-G071-template.xlsx

	B	C	D	E	F
1
2	AARC-G071 Guidelines for Secure Operation of Attribute Authorities and issuers of statements for entities review sheet
3	Operator				Peers:
4	AA scope
5	Model
6	Product(s)
7	Interop				Date of last update:
8
9	This assessment sheet supports the evaluation of the AARC-G071 "AAOPS" guidelines. Please refer to the Guidelines document https://aarc-community.org/guidelines/aarc-g071/ for the full description, requirements, and supporting documentation. Please clone this sheet for your own assessment.
10
11
12	Item	Description	Status	References	Review comments
13			OK, PARTIAL, N/A	link to document(s) and/or description of implementation, or substantiation	suggestions (by self or peers) on recommendations, next steps, and planned changes

14	AN-1	Identifiers of the AA Operator and the AA must both be non-reassigned and globally unique.
15	AN-1.2	In addition, the identifier of the Community should be unique.
16	AN-1.3	Community User Identifiers for subjects and attributes should be chosen in accordance with the AARC Guidelines and the Community Membership Management policy [AARC-G003].
17	AN-1.4	The AA must use a defined naming scheme for subjects and attributes.
18	AN-1.5	Subject identifiers must be non-reassigned and unique within an AA.
19	AMR-1	The Community must define and document the semantics, lifecycle, data protection, and release policy of attributes stored or asserted by the AA.			In a shared multi-tenancy setup where the AA Operator is the controller, this is actually defined by the operator, not the Community. The semantics must align with the AARC Guidelines, so is not only the community. So "The Controller must define ..." The "Owner" or "Service Owner" is better than AA operator in those fields, or Community
20	AMR-1.2	semantics
21	AMR-1.3	lifecycle
22	AMR-1.4	data protection
23	AMR-1.5	attribute release policy			"Policy" here is unclear - reword to clarify that this defined the attributes needed by the RPs
24	AMR-2	The AA Operator must implement the community definitions as defined and documented, for all the AAs it operates.			This is rather a relationship between AA operator and the customer, and either is not relavant or implicit (shared instance) or subject to the contract terms
25	AMR-3	It is recommended that the AA Operator provide a capability for the community to publish documents defining the attribute set and the semantics used by the community, for the benefit of Relying Parties.			All is related to the owner of the service (that may not be the Community). So the recommendation is on "the AA Provider"
26	AMR-4	The AA must only issue assertions or release attributes in accordance with the policies that are applicable to the Community
27	AMR-5	When a community engages multiple AA Operators or operates multiple AAs, the community must ensure that the assertions issued are consistent between all issuers.			This _could_ be interpreted also as a technical decision, where the AA is operated by two different entities on behalf of the community
28	AMR-6	The community should ensure that within one assertion issued attributes are consistent.
29	AAS-1	Assertions provided by an AA must be integrity-protected. They must be signed by the identified AA, or be transmitted over an integrity-protected channel where the server has been authenticated, and preferably both.
30	AAS-2	In addition to meeting its own regulatory obligations, the AA must respect data protection requirements of the Community.
31	AAS-2.2	It is recommended that AAs require client authentication, in addition to the encryption of the messages and the communication channel.			"... and/or the communications channel"
32	AAS-2.3	The AA should not send more data than required by the RP.
33	AAS-3	If an AA Operator issues assertions containing a lifetime, this lifetime must be compliant with the Community policies, as short as reasonably possible, and the assertion must not be valid beyond the validity period of the attributes it contains. The Community Management is responsible for the content of the assertion, as issued, during its entire lifetime			(current practices works out at ~ 1 week/10 days/ 1Ms for refresh tokens)
34	AAS-4	Re-issuance of assertions must be based on information held in the AA at the time of re-issuance.			(info returned from the userino endpoint matches what the accesstoken is based on, since that is what the user approved at that time, and no more -- and the validity period for access tokes is short. On changes, the access and refresh tokens is revoked on change in the information - hence it isperfect by design in eTShared)
35	OE	Implementers of AAs should use placement policies to ensure physical and/or virtual separation of sensitive and non-sensitive services, containers, or virtual machines, to reduce the risk of cross-compromise, taking into account both the integrity of the AA as well as the requirements of the communities hosted on the AA and the Relying Parties receiving attributes
36	OE-1	Through its personnel or by contractual measures, the AA Operator should ensure appropriate controls are in place over the security context.
37	OE-2	The AA must be located in a physically secure environment where access is controlled and limited to specific trained personnel.
38	OE-3	The protections on the AA and its operational environment, including the credentials of the AA administrators and operators, should meet or exceed the requirements of all of the communities hosted in the AA.
39	KM-1	A key used to protect assertions should be dedicated to assertion protection functions.
40	KM-2	Keys must not be shared between AA Operators. A single AA Operator may use the same signing key for multiple AAs. Where multiple AAs are under the control of a single AA operator but located in physically distributed locations, the key must only be transported using secure protocols.
41	KM-3	Keys must have a protection strength equivalent to 112 bits (symmetric) or higher.
42	KM-4	Keys must only be accessible by the service and by trained personnel subject to procedural controls.
43	KM-5	AA Operators are recommended to use an HSM to store signing keys.
44	KM-5.2	When using software-based private keys, such keys must be suitably protected by the operating system. Keys should not be held unencrypted on persistent storage protected solely by database, storage and file system level permissions.			Is very hard in a dynamic "breathing" mode for container management. Yet: where is the unprotected key from that is being prvisioned? HSMs will be better, but needsome investigation... TMPFS holding decryption keys is actually a compliant implementation!
45	NET-1	The network to which the AA system is connected must be highly protected and suitably monitored.
46	SITE-1	The AA Operator must ensure appropriate site security controls are in place and maintained in a state consistent with the security requirements of the hosted Communities.
47	MD-1	The AA Operator must publish, to the Community and related Relying Parties, at least the following metadata for each AA it hosts [generic requirement: the AA operator has a meta-data publishing end-point]
48	MD-1.1a	administrative contact details for the AA Operator, including at least one role-based email address and one postal contact address
49	MD-1.1b	an operational security contact for the AA Operator, being at least a role-based email address but preferably including a telephone number			... but MAY include a ....
50	MD-1.1c	cryptographic key material required to verify signed messages, where that is required to validate issued attribute assertions
51	MD-2	It is recommended that the AA Operator publishes, where available [generic requirement: the AA operator has a web site]
52	MD-2.1a	such validated trust marks as are relevant to the evaluation of the security and trust of the AA by the Communities, Identity Providers, and Relying Parties			Sirtfi, R&S, AAOPS G071, ...
53	MD-2.1b	a (web) URL to a general information web page about the Community.
54	MD-3	The AA Operator should provide a means to validate the integrity of its roots of trust.			For OIDC well-known, use OV https
55	AR-1	The attributes in the AA and their binding to subjects must be verifiable and assessable.
56	AR-2	The AA Operator must log, for the purpose of traceability in support of security incident response, where the AA provides relevant attributes, at least the following for all of its hosted AAs
57	AR-2.1a	all requests for attributes and all issued attribute assertions, to the extent that they are needed to allow traceability of attribute release to individuals during incident response by receiving qualified Relying Parties
58	AR-2.1b	any configuration change to the AA relevant to the access control of the attribute repository
59	AR-2.1c	any change affecting the binding between subjects and attributes
60	AR-2.2	The AA Operator, in its published privacy and confidentiality policies must permit logging as required above.
61	AR-3	The AA Operator must log at least the following for its AA issuance systems, for the purposes of incident response:
62	AR-3.1a	all login, logout, reboot, and key activation events of the issuing system
63	AR-3.1b	changes to the configuration of the issuing system
64	AR-4	The AA Operator must keep records regarding attribute release and its issuance systems after termination of the effects of the auditable events for as long as required by the Community and any Relying Parties that have entered into an agreement with the AA Operator, and as required by applicable legislation.			"... for as long as required." Full Stop.
65	AR-5	The AA operator must disclose and discuss, on request, those aspects of their operational environment that are relevant to the evaluation of the security and trust by the Communities and Relying Parties
66	AR-6	The AA Operator must be able and willing to collaborate with affected organisations in the management of a security incident
67	AR-7	The AA Operator should review roles, rights, and access of its staff at least once per year
68	PC-1	The AA operator must define and publish a privacy and data release policy, and that policy must be compatible with the assertions that it issues, and be compliant with relevant legislation
69	BCDR-1	The AA Operator must have a compromise and disaster recovery procedure ...
70	BCDR-1.2	... and a business continuity plan
71	BCDR-2	The business continuity and disaster recovery plan must be compatible with the requirements of the hosted Communities.			what are the requirements? Do the community have a say?
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100