| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | DocNumber | Other Identifiers | Title | Keywords | Abstract | Status | DocURL | DOI | Work area URL | GuardianAngel | ||||||||||||||||||
2 | AARC-G001 | AARC1-JRA1.4Av1 | Expressing group membership and role information | Superseded | https://aarc-project.eu/wp-content/uploads/2017/03/AARC-JRA1.4A.pdf | |||||||||||||||||||||||
3 | AARC-G002 | AARC1-JRA1.4Av2 | Expressing group membership and role information | This document standardises the way group membership information is expressed. It defines a URN-based identification scheme that supports: indicating the entity that is authoritative for each piece of group membership information; expressing VO membership and role information; representing group hierarchies. | Final | https://aarc-project.eu/wp-content/uploads/2017/11/AARC-JRA1.4A-201710.pdf | https://docs.google.com/document/d/1LGTsi5ySNxz6lWCSHEV24ypRPjVqkQZlB9oMsj5d7k4/edit# | |||||||||||||||||||||
4 | AARC-G003 | AARC1-JRA1.4B | Attribute aggregation | This document discusses attribute aggregation scenarios applied in international research collaborations. Attribute aggregation can take place at proxy, SP or TTS services, in-line with the Blueprint Architecture. | Final | https://aarc-project.eu/wp-content/uploads/2017/03/AARC-JRA1.4B.pdf | ||||||||||||||||||||||
5 | AARC-G004 | AARC1-JRA1.4C | Token Translation Services | Token translation operation might happen “seamlessly” to the user, or it may require an action from the user in order to perform the token translation operation. These guidelines consider consistency of user information, deployment options, security, and transparency and data minimisation. | Final | https://aarc-project.eu/wp-content/uploads/2017/03/AARC-JRA1.4C.pdf | ||||||||||||||||||||||
6 | AARC-G005 | AARC1-JRA1.4D | Credential Delegation | In distributed environments it is often necessary for a remote service to access other services on behalf of a user, or for a software agent to act on behalf of the user. This guidelines consider delegation of credentials based on signed assertions, session tickets, “tokens” of various types, and proxy certificates. | Final | https://aarc-project.eu/wp-content/uploads/2017/03/AARC-JRA1.4D.pdf | ||||||||||||||||||||||
7 | AARC-G006 | AARC1-JRA1.4E | Best Practices for managing authorisation | This document provides best practices for a range of models for Authorisation policy enforcement that apply at service providers end-points, even if not always solely on the resource SP alone, e.g. in the case of an IdP/SP proxy. | Final | https://aarc-project.eu/wp-content/uploads/2017/03/AARC-JRA1.4E.pdf | ||||||||||||||||||||||
8 | AARC-G007 | AARC1-JRA1.4F | Non-browser access | Overview of non-web access mechanisms in common use for both interactive (command-line) access and for API based access. Mechanisms based on ssh, PKIX/X.509, API keys and OIDC are reviewed and placed in context. | Final | https://aarc-project.eu/wp-content/uploads/2017/03/AARC-JRA1.4F.pdf | ||||||||||||||||||||||
9 | AARC-G008 | AARC1-JRA1.4G | implementing SAML authentication proxies for social media identity providers | This guidelines provides recommendations and best practices for implementing authentication proxies that can connect social media identity providers with federated SAML 2.0 service providers. | Final | https://aarc-project.eu/wp-content/uploads/2017/03/AARC-JRA1.4G.pdf | ||||||||||||||||||||||
10 | AARC-G009 | AARC1-JRA1.4H | Account linking and LoA elevation use cases and common practices for international research collaboration | In Identity linking (account linking) the user’s infrastructure identity is associated with external identities, i.e. created and assigned outside of the administrative boundaries of the infrastructure, such as institutional IdPs or social media IdPs. This linking may be either implicit or explicit to the user. The document reviews use cases and considers consistency of representation, accounting, and tracability of linked identities. | Final | https://aarc-project.eu/wp-content/uploads/2017/03/AARC-JRA1.4H.pdf | ||||||||||||||||||||||
11 | AARC-G010 | AARC1-JRA1.4I | Best practices and recommendations for attribute translation from federated authentication to X.509 credentials | This guideline suggests the common way to encode authentication and authorization in X.509 credentials, to increase the re-usability and interoperability of X.509 credentials generated by token translation services. | Final | https://aarc-project.eu/wp-content/uploads/2017/03/AARC-JRA1.4I.pdf | ||||||||||||||||||||||
12 | AARC-G011 | AARC-BPA-2016 | AARC Blueprint Architecture 2016 | Superseded | https://aarc-project.eu/architecture/aarc-bpa-2016/ | |||||||||||||||||||||||
13 | AARC-G012 | AARC-BPA-2017 | AARC Blueprint Architecture 2017 | The AARC Blueprint Architecture (BPA) provides set of interoperable architectural building blocks for software architects and technical decision makers, who are designing and implementing access management solutions for international research collaborations. | Final | https://aarc-project.eu/wp-content/uploads/2017/04/AARC-BPA-2017.pdf | ||||||||||||||||||||||
14 | AARC-G013 | AARC1-MNA3.1 | Recommandations on minimal assurance level relevant for low-risk research use cases | For the risk management of the research services relying on the federated AAI, it is important to determine the assurance level available for the authenticated users. This document defines requirements for a minimal assurance level which is still relevant for low-risk research use cases. | Final | https://aarc-project.eu/wp-content/uploads/2015/11/MNA31-Minimum-LoA-level.pdf | https://wiki.geant.org/display/AARC/MNA3.1%3A+Recommendations+on+Minimal+Assurance+Level+Relevant+for+Low-risk+Research+Use+Cases | |||||||||||||||||||||
15 | AARC-G014 | SIRTFI-v1 | Security Incident Response Trust Framework for Federated Identity | Sirtfi provides a mechanism to identify trusted, operationally secure eduGAIN participants and facilitate effective incident response collaboration. | Endorsed REFEDS | https://aarc-project.eu/policies/sirtfi/ | https://wiki.refeds.org/display/SIRTFI | |||||||||||||||||||||
16 | AARC-G015 | SNCTFI-v1 | Scalable Negotiator for a Community Trust Framework in Federated Infrastructures | Snctfi identifies operational and policy requirements to help establish trust between an infrastructure and identity providers either in an R&E federation. | Endorsed IGTF | https://aarc-project.eu/wp-content/uploads/2017/07/Snctfi-v1.0.pdf | https://doi.org/10.5281/zenodo.1173109 | https://igtf.net/snctfi/ | ||||||||||||||||||||
17 | AARC-G016 | AARC1-DNA3.5 | Recommendations on the exchange of personal data in accounting data sharing | provide templates for policies that operators of different components in the infrastructures can use. It provides updates about the legal context and identifies the minimal set of information needed by the participants in the prevalent use cases | Final | https://aarc-project.eu/wp-content/uploads/2016/12/AARC-DNA3.5_Recommendations-for-Processing-Personal-Data_2016_11_07_v4_DG.pdf | https://wiki.geant.org/display/AARC/DNA3.5%3A+Recommendations+and+template+policies+for+the+processing+of+personal+data | UrosS | ||||||||||||||||||||
18 | AARC-G017 | not-assigned | ||||||||||||||||||||||||||
19 | AARC-G018 | not-assigned | ||||||||||||||||||||||||||
20 | AARC-G019 | not-assigned | ||||||||||||||||||||||||||
21 | AARC-G020 | not-assigned | ||||||||||||||||||||||||||
22 | AARC-G021 | AARC2-JRA1.1A | Exchange of specific assurance information between Infrastructures | Infrastructures and generic e-Infrastructures compose an ‘effective’ assurance profile derived from several sources, yet it is desirable to exchange the resulting assurance assertion obtained between Infrastructures so that it need not be re-computed by a recipient Infrastructure or Infrastructure service provider. This document describes the assurance profiles recommended to be used by the Infrastructure AAI Proxies between infrastructures: REFEDS RAF Cappuccino and Espresso, IGTF-BIRCH and IGTF-DOGWOOD, and a profile addressing assurance partially derived from social-identity sources: AARC-Assam. | Final Endorsed AEGIS | https://aarc-project.eu/wp-content/uploads/2018/02/AARC-G021-Exchange-of-specific-assurance-information-between-Infrastructures.pdf | https://doi.org/10.5281/zenodo.1173558 | https://wiki.geant.org/display/AARC/AARC2-JRA1.1A+--+Guideline+on+the+exchange+of+specific+assurance+information+between+Infrastructures | DavidG | |||||||||||||||||||
23 | AARC-G022 | AARC2-JRA1.1B | Discovery of authoritative attribute providers across different operational domains | Concept | ||||||||||||||||||||||||
24 | AARC-G023 | AARC2-JRA1.1C | Handling user registration and user consent for releasing attributes across different operational domains | Concept | ||||||||||||||||||||||||
25 | AARC-G024 | AARC2-JRA1.1D | Federated access to non-web services across different operational domains | Concept | ||||||||||||||||||||||||
26 | AARC-G025 | AARC2-JRA1.1E | Expressing affiliation information across infrastructures | This document describes the semantics associated with the use of the affiliation attributes when these are asserted by an Infrastructure Proxy when communiting to connected service providers and other Infrastructure Proxies. | Final Endorsed AEGIS | https://wiki.geant.org/display/AARC/AARC2-JRA1.1E+--+Guidelines+for+the+exchange+of+affiliation+information+between+infrastructures | ||||||||||||||||||||||
27 | AARC-G026 | AARC2-JRA1.1F | Guidelines for expressing unique user identifiers across infrastructures | A variety of different user identifiers in different formats is used by research infrastructures and e-infrastructures. The goal of this document is to define how the user identifiers should be expressed when transported across AARC BPA-compliant AAIs. Different strategies for generating these identifiers are also proposed. | Final Endorsed AEGIS | https://wiki.geant.org/display/AARC/AARC2-JRA1.1F+--+Guidelines+for+uniquely+identifying+users+across+infrastructures | ||||||||||||||||||||||
28 | AARC-G027 | AARC2-JRA1.2A | Guidelines for expressing capabilities | Managing authorisation at each SP individually does not scale, even if occasionally it might today be required. This guideline addresses management of authorisation across multiple SPs, possibly operated by different entities. For some cases centrally managed entitlements (conveying group/role membership for example) are proposed as sufficient. | Final Endorsed AEGIS | https://wiki.geant.org/display/AARC/AARC2-JRA1.2A+--+Authorisation | ||||||||||||||||||||||
29 | AARC-G028 | AARC2-JRA1.2B | Requirements and guidelines for federated access to OIDC-based services in the context of research collaboration | This document captures what OIDC-based services need to understand and which schemes to follow in order to benefit from federated identities that currently are exclusively existent in the 'SAML world'. It includes references to specific mappings between SAML and OIDC expression of attributes, entitlements or claims, and should be considered in conjunction with AARC-G032 "Guidelines for registering OIDC Relying Parties in AAIs for international research collaboration" | On Hold | https://wiki.geant.org/display/AARC/AARC2-JRA1.2B+--+OIDC-based+services+in+research+collaborations | ||||||||||||||||||||||
30 | AARC-G029 | AARC2-JRA1.2C | Guidelines on stepping up the authentication component in AAIs implementing the AARC BPA | A number of research community use cases require users to verify their identity by using more than one type of credentials, for instance using password authentication, together with some physical object such as a phone or usb stick that generates tokens/pins, etc. At the same time, there are services that may require an already logged in user to re-authenticate using a stronger authentication mechanism when accessing sensitive resources. Authentication step-up is then needed to improve the original authentication strength of those users. This document provides guidelines on step-up of the authentication component. It covers requirements and implementation recommendations, describes a proposed authentication step-up model, and outlines related work and documentation. | Final | https://aarc-project.eu/wp-content/uploads/2018/05/AARC-G029_Guidelines-on-Step-Up-Authentication.pdf | https://doi.org/10.5281/zenodo.1251671 | https://wiki.geant.org/display/AARC/AARC-G029+-+Guidelines+on+stepping+up+the+authentication+component+in+AAIs+implementing+the+AARC+BPA | Marcus | |||||||||||||||||||
31 | AARC-G030 | AARC2-JRA1.2D | Requirements and Implementations for Authentication Freshness | This document describes mechanisms for forcing a user to perform an additional login (reauthentication) in order to ensure that the user who is accessing a protected resource is the same person who initially authenticated at the start of the session. Forced reauthentication can therefore provide additional protection for sensitive resources. | In Progress | https://wiki.geant.org/display/AARC/AARC2-JRA1.2D+--+Authentication+freshness | Marcus | |||||||||||||||||||||
32 | AARC-G031 | AARC2-JRA1.3A | Guidelines for evaluating the combined assurance of linked identities | This document investigates the use of Account Linking to evaluate the combined Assurance of identities, taking into account use cases related to different sectors. It defined an LoA evaluation model based on the REFEDS Assurance Framework, demonstrates possible outcomes of different LoAs combinations, and defines a combined LoA evaluation model. | Final Endorsed AEGIS | https://wiki.geant.org/display/AARC/AARC2-JRA1.3A+--+Guidelines+for+evaluating+the+combined+assurance+of+linked+identities?src=contextnavpagetreemode | Davide | |||||||||||||||||||||
33 | AARC-G032 | AARC2-JRA1.3B | Registering OIDC Relying Parties in AAIs for international research collaboration | This document describes different ways to accomplish an OpenID Connect client registration, specifically providing guidance for International Research Collaborations that need to implement one of these systems. | In Progress | https://wiki.geant.org/display/AARC/AARC2-JRA1.3B+--+Guidelines+for+registering+OIDC+Relying+Parties+in+AAIs+for+international+research+collaboration | Davide | |||||||||||||||||||||
34 | AARC-G033 | AARC2-JRA1.3C | AAI interoperability with non-R&E Identity Providers in support of international research collaboration | Concept | ||||||||||||||||||||||||
35 | AARC-G034 | AARC2-JRA1.3D | AAI interoperability with eIDAS Identity Providers in support of international research collaboration | Concept | ||||||||||||||||||||||||
36 | AARC-G035 | AARC2-JRA1.3E | AAI tools & technologies enabling OIDC for international research collaboration | Concept | ||||||||||||||||||||||||
37 | AARC-G036 | AARC2-JRA1.4A | Roles, responsibilities and security considerations for VOs | Virtual Organisations (VOs) have several roles and responsibilities; some are identified as community responsibilities, and others arise from relations to infrastructures (e.g. security contact, technical contact). Can we minimise the number of places that need this information, in order to improve maintainability and scalability? | In Progress | https://wiki.geant.org/display/AARC/AARC2-JRA1.4A+--+Roles%2C+responsibilities+and+security+considerations+for+VOs | Nicolas | |||||||||||||||||||||
38 | AARC-G037 | AARC2-JRA1.4B | Combining group membership and role information in multi-AA environments | When combining information from several AAs, one needs to consider the different semantics, different levels of assurance, and different purposes of the AAs and their attributes. | In Progress | https://wiki.geant.org/display/AARC/AARC2-JRA1.4B+Combining+multi-AA+roles | Jens | |||||||||||||||||||||
39 | AARC-G038 | AARC2-JRA1.4C | Scalable account (de)provisioning of VO members | Concept | ||||||||||||||||||||||||
40 | AARC-G039 | AARC2-JRA1.4D | Implementing, operating and using VO platforms | Concept | ||||||||||||||||||||||||
41 | AARC-G040 | Preliminary Proxy Policy Recommendations (application to the LS AAI) | The Life Sciences AAI Infrastructure Proxy, developed in joint collaboration with EGI, EUDAT and GÉANT, is to be operated for the Life Sciences community by the joint e-Infrastructures. As the pilot enters its second phase the LS AAI has to declare compliance to R&S and CoCo towards the R&E federations. This document provides preliminary guidance for the operators of the pilot LSAAI. | Final | https://wiki.geant.org/display/AARC/AARC-G040+Preliminary+Proxy+Policy+Recommendations%3A+application+to+the+LS+AAI | DavidG | ||||||||||||||||||||||
42 | AARC-G041 | Expression of REFEDS RAF assurance components for identities derived from social media accounts | Infrastructure Proxies may convey assurance information derived from multiple sources, one of which may be ‘social identity’ sources. This guidance explains under which conditions combination of assurance information and augmentation of identity data within the Infrastructure Proxy should result in assertion of the REFEDS Assurance Framework components “unique identifier”, and when it may be appropriate to assert the “identity proofing” component value low. | Final | https://wiki.geant.org/display/AARC/AARC-G041+Expression+of+REFEDS+RAF+assurance+components+for+identities+derived+from+social+media+accounts | DavidG | ||||||||||||||||||||||
43 | AARC-G042 | Data Protection Impact Assessment - an initial guide for communities | This report presents the results of the desk study on the evaluation of risks to (personal) data protection as considered in the European General Data Protection Regulation (GDPR), for Infrastructures and their service providers that leverage federated identity management (FIM) to connect research and collaboration users. Specifically, it considers personal data collected as a result of using the infrastructure (not any risks relating to the research data itself, which is a community responsibility) and provides guidance to the Infrastructures concerning Data Protection Impact Assessment (DPIA) in the FIM context. The authors present recommendations to Research Communities for determining the necessity of formal DPIA and guidelines for its execution. This report does not constitute legal advice in any specific jurisdiction. | Final | https://wiki.geant.org/display/AARC/DPIA+Risk+Assessment+for+Proxies+-+AARC2-DNA3.1 | |||||||||||||||||||||||
44 | AARC-G043 | Guidelines for expressing friendly names of user and community information | Concept | |||||||||||||||||||||||||
45 | AARC-I044 | Implementers Guide to the WISE Baseline Acceptable Use Policy | Applying the Baseline AUP to concrete use cases may appear straightforward, but there are many edge cases and specific circumstances where it is not entirely obvious how to both achieve the aim of user-friendliness as well as be complete and practical. In this write-up, we try to give hints how to use the WISE Baseline AUP in practice in both community-first as well as ‘user-first’ membership management services. | Draft | https://docs.google.com/document/d/1tGghpHCKTu8sTO1wNrJBXXfD0N1XDAmFTn9b8t6wzPE/edit# | DavidG | ||||||||||||||||||||||
46 | AARC-G045 | AARC-BPA-2019 | AARC Blueprint Architecture 2019 | The AARC Blueprint Architecture (BPA) provides set of interoperable architectural building blocks for software architects and technical decision makers, who are designing and implementing access management solutions for international research collaborations. | Draft | https://docs.google.com/document/d/1yIU66Y_9KSLVr6zCFvYdg0QAkS-oFA-oPN4l66iCA5w/edit | ||||||||||||||||||||||
47 | AARC-I046 | Thoughts on attribute assurance metadata | ||||||||||||||||||||||||||
48 | AARC-I047 | Implementing scalable and consistent authorisation across multi-SP environments | https://www.google.com/url?q=https://docs.google.com/document/d/18Me5b63R7GKb_1gDfYH02l2sXr3mCIg_suPRw86Ye7I/&sa=D&ust=1552932286790000&usg=AFQjCNH3g8grHAaCm_bPWd66r0lxwW9Frg | |||||||||||||||||||||||||
49 | AARC-G048 | IGTF AAOPS Guideline | Guidelines for Secure Operation of Attribute Authorities and other issuers of access statements | operational-security | These guidelines describe the minimum requirements and recommendations for the secure operation of Attribute Authorities and similar services providing statements for the purpose of obtaining access to infrastructure services. Stated compliance with these guidelines may help to establish trust between issuers and Relying Parties | Final | https://aarc-project.eu/wp-content/uploads/2019/05/AARC-G048.pdf | https://doi.org/10.5281/zenodo.3234926 | https://docs.google.com/document/d/1k1Xdk456cq6ILiodqkmRJRevBWzfWjwau9tkuRjIAWQ/edit# | DavidG, Hannah | ||||||||||||||||||
50 | AARC-G049 | Specification for IdP hinting | This document defines a generic browser-based protocol for conveying – to services – hints about the IdPs or IdP-SP-proxies that should be used for authenticating the principal. This protocol, colloquially referred to as Identity Provider (IdP) hinting, can greatly simplify the discovery process for the end-user, by either narrowing down the number of possible/IdPs to choose from or by making the actual selection process fully transparent. | Endorsed by AEGIS | https://aarc-project.eu/wp-content/uploads/2019/04/AARC-G049-A_specification_for_IdP_hinting-v6.pdf | Nicolas | ||||||||||||||||||||||
51 | AARC-I050 | Comparison Guide to Identity Assurance Mappings for Infrastructures | Assurance frameworks and their specific profiles originate in several different forums, each brining a particular background and viewpoint to the assurance ecosystem: REFEDS, IGTF, Kantara, NIST, and eIDAS being some of them. This document provides background information on the mapping between those assurance frameworks and guidance on appropriate assurance frameworks for the various use cases | Final | https://wiki.geant.org/download/attachments/114935014/ComparisonGuidetoAssuranceMapping-v01-20190228.pdf | https://wiki.geant.org/pages/viewpage.action?pageId=114935014 | DavidG, IanN | |||||||||||||||||||||
52 | AARC-I051 | Guidelines on Federated Security Incident Response for Research Communities (Sirtfi Communications model) | procedures for Federation Participants, Federation Operators and Interfederation Operators during security incident response. It is assumed that Sirtfi has the support of all Federations and the compliance of all Federation Participants. This is a proposal produced by the AARC project and it is expected that work will continue within the REFEDS Sirtfi Working Group to define sustainable incident response capabilities for interfederation. | Final | https://aarc-project.eu/wp-content/uploads/2019/03/AARC-I051-Guide-to-Federated-Security-Incident-Response-for-Research-Collaboration.pdf | https://wiki.geant.org/display/AARC/Generic+Security+Incident+Response+Procedure | Hannah, DavidG | |||||||||||||||||||||
53 | AARC-G052 | OAuth 2.0 Proxied Token Introspection | To be reviewd by AEGIS | https://docs.google.com/document/d/11Amv6kjPvVVgWB71iEaj6NcrhlNzht7HP9GJK6cNOS8/edit# | ||||||||||||||||||||||||
54 | AARC-G053 | Specification for expressing user authentication via REFEDS R&S and/or Sirtfi compliant IdP | Concept | https://docs.google.com/document/d/1G4L7Gb4j6XBtqx0G1ey6JtflgDopHl_eO3VWb-O8eXI/edit# | ||||||||||||||||||||||||
55 | AARC-G054 | Specification for expressing authenticating authorities | Concept | https://docs.google.com/document/d/1OT7_l8i14oGbhkilzbS5ZvFMut5EBJvgth_27s0gpBY/edit# | ||||||||||||||||||||||||
56 | AARC-G055 | AARC Blueprint Architecture 2020 | Concept | |||||||||||||||||||||||||
57 | AARC-G056 | AARC profile for expressing community identity attributes | voPerson | This document defines a profile for expressing the attributes of a researcher’s digital identity. The profile contains a common list of attributes and definitions based on existing standards and best practises in research & education. The attributes include identifiers, profile information, and community attributes such as group membership and role information. | Concept | |||||||||||||||||||||||
58 | AARC-G057 | Inferring and constructing origin-affiliation information across infrastructures | voPerson | Conveying affiliation information from origin providers across infrastructures proxies as defined in G025 is only possible if the origin identity provider releases such information. In case no eduPersonScopedAffiliation is provided, it may be partially reconstrucuted according to these guidelines. If there is no reliable way to infer origin affiliation, no such affiliation should be asserted by infrastructure proxies. | Draft | https://docs.google.com/document/d/1GM5mMMXwtXsr3NqteG2rMQ3oEQOFkgo_hEHrw4RQsh0 | https://wiki.geant.org/display/AARC/Inferring+and+constructing+origin-affiliation+information+across+infrastructures | DavidG | ||||||||||||||||||||
59 | AARC-G058 | Establishing trust between OAuth 2.0 Authorization Servers | OIDCFed-0.1 | Draft | https://docs.google.com/document/d/18bvC63O3wti8nw5lhgUbBVMtDG9ggqpe5ad8Om9voBo/edit | |||||||||||||||||||||||
60 | AARC-G059 | Expressing affiliation information (Revision of G025) | Draft | https://docs.google.com/document/d/15eK80-h9SwPka0EYhbpI3QwJIW2Bt-URkf0jfIeuinY/edit# | ||||||||||||||||||||||||
61 | AARC-G060 | A followup on IdP hinting | Concept | https://docs.google.com/document/d/1sTULdoIz6NCa0tC4YecAhfe-gu37i7O6AhCIgXMmGMo | Marcus | |||||||||||||||||||||||
62 | AARC-G061 | A specification for IdP hinting | Endorsed by AEGIS | 10.5281/zenodo.4596667 | https://docs.google.com/document/d/187uHuBeL2iOlMUrgTarU8_joj5TXNp9hXz9IyGsyy6o | Marcus | ||||||||||||||||||||||
63 | AARC-G062 | A specification for hinting an IdP which discovery service to use | Endorsed by AEGIS | 10.5281/zenodo.5763858 | https://docs.google.com/document/d/1a99MlLQkYqXm8iOhq3GCorTrtX6EBzcHrr6XeW-qgg0 | Marcus | ||||||||||||||||||||||
64 | AARC-G063 | A specification for providing information about an end service at an IdP | Endorsed by AEGIS | 10.5281/zenodo.6938616 | https://docs.google.com/document/d/1mj_3kTtUdqBye96x-LyT4KaAJTXpBPWNojlKMgBEZBU | Marcus | ||||||||||||||||||||||
65 | AARC-G064 | A specification for passing hints to Discovery Services | Beta | https://docs.google.com/document/d/1rHKGzPsjkbqKHxsPnCb0itRLXLtqm-A8CZ5fzzklaxc | Marcus | |||||||||||||||||||||||
66 | AARD-G065 | AARC VERSION | ||||||||||||||||||||||||||
67 | AARC-G0XX | A template for hinting documents (maybe helpful for others) | Done | https://docs.google.com/document/d/1l7skOSAd8QQkXNJy7-wxEFcEC3iZy9hZ1t-JAFk9rr0 | Marcus | |||||||||||||||||||||||
68 | AARC-G065-G068 | We'd like to block a few for future hinting parameters (if any) | Marcus | |||||||||||||||||||||||||
69 | AARC-G069 | Revision of G002 | Endorsed by AEGIS | https://docs.google.com/document/d/1m-syP-f1fsU0bmjY6AzZLuPIL6l_hAMGD01Q_kFocXI/edit# | 10.5281/zenodo.6533400 | |||||||||||||||||||||||
70 | AARC-G070 | Expression of primary group Membership | Draft | https://docs.google.com/document/d/1kIDpSyGNwZPeEkIRvfFolEGPFZA0yd2IJ5vlJdJIFus | ||||||||||||||||||||||||
71 | AARC-G071 | Guidelines for Secure Operation of Attribute Authorities and other issuers of access-granting statements | attribute authority, operational-security, | These guidelines, updating AARC-G048, provide recommendations for the secure operation of attribute authorities, attribute proxies, and similar services. Stated compliance with these guidelines may help to establish trust between issuers and Relying Parties, and provides good practice recommendations for protecting a community's membership attributes. | Endorsed by AEGIS | https://aarc-community.org/guidelines/aarc-g071/ | https://doi.org/10.5281/zenodo.5927798 | https://docs.google.com/document/d/1-hbqSpQegm7UaC_wupFzFMm19Q024UPkG-8Jwokkmzc/edit | DavidG | |||||||||||||||||||
72 | AARC-G072 | Guidelines for expressing service account information | Robot accounts, Service Accounts, Guest, ... | A set of recommendations on how to describe and identify service (aka "robot") accounts. | Collecting Input | https://docs.google.com/document/d/1-SM6udRKamxmSx6L2tWYoDViXA88xnnl48y7lCZjVVw/edit | Marcus | |||||||||||||||||||||
73 | AARC-G073 | Guidelines for Refreshing Tokens between OAuth 2.0 Proxies | Refresh Tokens, OAuth 2.0 | |||||||||||||||||||||||||
74 | AARC-G079 | Specification of AARC Entity Categories | To be reviewd by AEGIS | https://docs.google.com/document/d/19HPPhiU8pjljzHafqTLiak732O7KS7CMYIRstlW1lJM/edit# | ||||||||||||||||||||||||
75 | AARC-G080 | AARC Blueprint Architecture 2022+ | ||||||||||||||||||||||||||
76 | AARC-G081 | Recommendation on Token Lifetimes | Tokens | Close to submission to AEGIS | https://docs.google.com/document/d/1U9vvJfWuE8oO7u0FcGVGr3KySvBqwjnkzKO8TKzgoX4/edit#heading=h.z2cwitkmh1xk | Marcus | ||||||||||||||||||||||
77 | AARC-I082 | Trust in Distributed Proxy Scenarios | trust, security policy, AAOps, Sirtfi, Snctfi | In this paper, we identify the smallest set of distinct guidelines (policies, good practices, procedures) necessary to cover trust, security, and operational interaction of proxies in composite-proxy scenarios beyond the community-and-infrastructure proxy doublet of AARC-G045. Some elements may already be in place, such as the attribute authority operations security guidance AARC-G071, others have only been identified as needed but have not yet been described in sufficient detail to formulate policy of good practice. The aim of this paper is to identify the smallest set of distinct guidelines, practices, and procedures needed. | Final | https://drive.google.com/drive/folders/1DOi77I0Tfu04AUVWKiaDDMhfLIF5yMxD | ||||||||||||||||||||||
78 | AARC-G083 | Notice Management by Proxies | AUP, privacy, terms-conditions | use of GDPR privacy notices and AUP acceptance practices in the current research infrastructures, and provide sectoral recommendations on aligning their presentation by AARC BPA proxies. Since different research infrastructures deal with data of varying sensitivity levels, the model shall allow for a scalable level of control and verifiability. | Final | https://drive.google.com/drive/folders/1ieu_URA_tx2lKCfipqynf69EbSpiqxbT | ||||||||||||||||||||||
79 | AARC-G084 | Security Operational Baseline for Proxies and Services | security policy, PDKv2 | The Security Baseline provides a reference set of minimum expectations and requirements of the behaviour of those offering services to users, communities, and other paricipants in a distributed proxy ecosystem, and of those providing access to services or assembling service components. It aims to establish a sufficient level of trust between all Participants in the Infrastructure to enable reliable and secure Infrastructure operation. | Importing | https://drive.google.com/drive/folders/13-MZqRnQPrHmQ4tW1ElYOvPMy_1XShuh | https://wiki.geant.org/display/AARC/AARC-G084+Security+Operational+Baseline | DavidG | ||||||||||||||||||||
80 | AARC-I085 | eID assurance model suitability assessment | assurance, wallet, EIDAS | Increased assurance in research services through eID identity assertions has proven hard to obtain from home identity providers in the R&E sector. It is more readily available in the European government identity ecosystem, and we will provide an assessment of its applicability for users of research infrastructures dealing with sensitive data through the proxies in the revised AARC BPA model. Step-up to at least a substantial level could then be done at “home” through the user’s national eID scheme. This document investigates capabilities for leveraging national eID for increased identity assurance for the benefit of research services. | Ongoing | https://docs.google.com/document/d/1s124B0DwCDGlgchTEAQy_NOHgYmuC8f7xs2O_l65j-M | https://wiki.geant.org/spaces/AARC/pages/1176567841/AARC-I085+eID+assurance+model+suitability+assessment | Niels van Dijk | ||||||||||||||||||||
81 | AARC-G086 | reserved PDKv2 | ||||||||||||||||||||||||||
82 | AARC-G087 | reserved PDKv2 | ||||||||||||||||||||||||||
83 | AARC-G088 | reserved PDKv2 | ||||||||||||||||||||||||||
84 | AARC-G089 | reserved PDKv2 | ||||||||||||||||||||||||||
85 | AARC-G090 | reserved PDKv2 | ||||||||||||||||||||||||||
86 | ||||||||||||||||||||||||||||
87 | ||||||||||||||||||||||||||||
88 | ||||||||||||||||||||||||||||
89 | ||||||||||||||||||||||||||||
90 | ||||||||||||||||||||||||||||
91 | ||||||||||||||||||||||||||||
92 | ||||||||||||||||||||||||||||
93 | ||||||||||||||||||||||||||||
94 | ||||||||||||||||||||||||||||
95 | ||||||||||||||||||||||||||||
96 | ||||||||||||||||||||||||||||
97 | ||||||||||||||||||||||||||||
98 | ||||||||||||||||||||||||||||
99 | ||||||||||||||||||||||||||||
100 |