Changes between Version 5 and Version 6 of GEC16Agenda/CodingSprint


Ignore:
Timestamp:
03/29/13 10:55:58 (11 years ago)
Author:
Aaron Helsinger
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • GEC16Agenda/CodingSprint

    v5 v6  
    3636=== Developers Coding Sprint Topics ===
    3737The actual topics will be dictated by the people in the room and their concerns, but we anticipate discussing
    38 topics first raised at the [wiki:GEC16Agenda/DevelopersGrabBag Aggregate Developers' Topics]
    39 session.
     38topics first raised at the [wiki:GEC16Agenda/DevelopersGrabBag Aggregate Developers' Topics] session. Expected topics include:
    4039 1. Stitching
    4140 2. Uniform Experimenter Environment (continued from the [wiki:GEC16Agenda/CommonExecutionEnv previous session])
    … …  
    4544 6. Other topics introduced by the community
    4645
    47 
    48 == 2. Uniform Experimenter Environment ==
    49 
    50 The session focused on the topic of establishing common API's for different Slice Authorities (SA) and Clearinghouses (CH) and Identity Providers (IDP) that may be available and trusted within a given clearinghouse.
     46== Summary ==
     47As usual, the coding sprint session was well attended, and included multiple useful parallel conversations. Several experimenters received hands on assistance with tutorials or research. Some side conversations furthered monitoring of racks. And at least one operator received assistance with a FOAM aggregate installation. Meanwhile at the front of the room, a group of aggregate and framework developers discussed several topics. First, the group continued the discussion of a [wiki:GEC16Agenda/CommonExecutionEnv Uniform Experimenter Environment]. Some side conversations dived into details of stitching, the stitching schema, and aggregates to control dynamic circuit networks. The bulk of the discussion focussed on establishing common API's for different Slice Authorities (SA) and Clearinghouses (CH) and Identity Providers (IDP) that may be available and trusted within a given clearinghouse. This conversation included representatives from [http://www.fed4fire.eu/ Fed4Fire], ProtoGENI, ExoGENI, ISI, the GPO, and others.
    5148
    5249Some background:
    53  * A User Authority is an entity that creates user credentials and provides and manages user attributes.
     50 * A User Authority is an entity that creates user credentials and asserts and manages user attributes.
    5451 * A Slice Authority is an entity that creates slice credentials that provide authorization from a trusted source that a given user is entitled to allocate resources for a given slice.
    55  * A Clearinghouse provides directory services to point to any authorities or other services that are trusted and supported by the federation associated with that clearinghouse. This includes recognized SA's and AM's (aggregate managers)
     52 * A Clearinghouse provides directory services to point to any authorities or other services that are trusted and supported by the federation associated with that clearinghouse. This includes recognized SA's and AM's (aggregate managers).
    5653 * The GENI federation contains its own services and resources but also services and resources provided by other partner federations,  which may contain their own SA's and IDPs. Thus GENI may have multiple SA's,  CH's and AM's. Conversely, a CH, SA or AM may belong to multiple federations.
    57  * Specifically, GENI currently supports three different SA's (PG, GPO and PL) and three different IDP's (also PG, GPO and PL). The SA's all provide different API's, though they generate slice credentials that are common and interoperating. The IDP's generate compatible user credentials as well
     54 * Specifically, GENI currently supports at least three different SA's (PG, GPO and PL) and three different IDP's (also PG, GPO and PL). The SA's all provide different API's, though they generate slice credentials that are common and interoperating. The IDP's generate compatible user credentials as well
    5855
    59 With an eye towards Solicitation 4 tool developers, the participants in the session agreed that it was desirable for there to be a set of common federation-level API's that enable a tool developer to speak to a list of SA's or CH's in a common manner.  We decided not to try to standardize IDP API's as these operations (creating users and ascribing attributes) are largely out-of-band operations. We agreed in principle to a common SA and CH API that would resemble the AM API in that it will contain lists of credentials and return [code, error, value] tuples and speak XML/RPC over SSL. The details of the API calls are still TBD: GPO took an action to provide a proposal in the near-term.
     56With an eye towards Solicitation 4 tool developers, the participants in the session agreed that it was desirable for there to be a set of common federation-level API's that enable a tool developer to speak to a list of SA's or CH's in a common manner.  We decided not to try to standardize IDP API's as these operations (creating users and ascribing attributes) are largely out-of-band operations. We agreed in principle to a common SA and CH API that would resemble the AM API in that it will contain lists of credentials and return [code, error, value] tuples and speak XML/RPC over SSL. The details of the API calls are still TBD: GPO took an action to provide a proposal in the near future.
    6057
    6158
    62