GEOSS Community Scenario · Web viewGenerate tutorial documentation for user registration, authentication, and SSO for placement in the Best Practices Wiki and distribution to data

Data Sharing Guidelines Working Group (DSGWG)Engineering ReportGEO Architecture Implementation

Pilot, Phase 5GEOSS Architecture Implementation Pilot

Phase 6

Version 0.98

Content developed by the GEO Architecture Implementation PilotLicensed under a Creative Commons Attribution 3.0 License

http://creativecommons.org/licenses/by/3.0/

http://www.ogcnetwork.net/AIpilot

GEO Architecture Implementation Pilot, Phase 5 Version: 0.98Data Sharing Guidelines Working Group Engineering Report Date: 2014/05/05

Revision HistoryVersion

Date Editor and Content providers

Comments

0.1 2013-DEC-10 Original template.

0.5 2013-DEC-28 Steven F. Browdy Initial content taken from Twiki and notes.

0.6 2014-FEB-26 Steven F. Browdy Expanded content from notes and slides.

0.7 2014-MAR-08 Steven F. Browdy Expanded content from notes and slides.

0.8 2014-APR-02 Steven F. Browdy Expanded content from notes and slides.

0.9 2014-APR-15 Steven F. Browdy Expanded content from notes and slides.

0.95 2014-APR-28 Steven F. Browdy Near final draft.

0.97 2014-MAY-04 Steven F. Browdy Added use metrics and licenses details.

0.98 2014-MAY-05 Steven F. Browdy Finalized use metrics and license details.

Document Contact Information

If you have questions or comments regarding this document, you can contact:Name Organization Contact Information

Steven F. Browdy OMS Tech, Inc. / IEEE [email protected]

Page 2

mailto:[email protected]


Table of Contents1. Introduction 6

1.1 Scope of this document 61.2 Activity key drivers 61.3 Summary of AIP-6 efforts 6

1.3.1 Results Summary 71.3.2 Recommendations Summary 8

1.4 Future work 9

2. Activity Background and Objectives 102.1 Authentication and SSO 10

2.1.1 Background 102.1.2 Objectives 11

2.2 Use Metrics 112.2.1 Background 112.2.2 Objectives 12

2.3 GEOSS Data-CORE Compatible Licenses 122.3.1 Background 122.3.2 Objectives 13

3. Authentication and Single Sign-On 143.1 Summary 143.2 Use Cases 143.3 Trust Gateways 213.4 Test Implementations 213.5 Results and Next Steps (conclusions and recommendations) 22

4. Use Metrics 244.1 Summary 244.2 Use Cases 254.3 Implementation Scenarios and Web Services 284.4 Test Implementations 294.5 Results and Next Steps (conclusions and recommendations) 29

5. GEOSS Data-CORE Compatible Licenses 325.1 Summary 325.2 Use of Metadata Standards and Metadata Fields 325.3 Use Cases 32

5.3.1 375.4 Test Implementations 375.5 Results and Next Steps (conclusions and recommendations) 37

6. Use Cases 386.1 AIP Engineering Use Cases 38

7. Implementation 417.1 Deployed Components 417.2 Interoperability Arrangements 417.3 Use of the GCI 417.4 Demonstration 41

Page 3


7.4.1 Detailed Storyboard 417.4.2 Demo video 41

7.5 Future plans for deployment 41

8. References 42

Page 4


List of FiguresFigure 1: Prototype SSO Federation for GEOSS..........................................................................................................22Figure 2: Use Metrics Component Deployment Strategy.............................................................................................30Figure 3 – GEOSS AIP Use Case Summary Diagram.................................................................................................38

List of TablesTable 1: AIP-6 DSGWG Contributors 6Table 4 – GEOSS Actors 38Table 5 – Publish Resources Use Cases 39Table 6 – Discover Resources Use Cases 39Table 7 –Visualize and Access Use Cases 40Table 8 – Process and Automate Use Cases 40Table 9 – Maintain and Support Use Cases 41

Page 5


Data Sharing Guidelines Working Group

1. Introduction

1.1 Scope of this documentThe AIP-6 Data Sharing Guidelines Working Group (DSGWG) Engineering Report (ER) provides information related to the research and development of three main areas of effort:

Authentication and Single Sign-On

Use Metrics

GEOSS Data-CORE Compatible Licenses

For each of these areas of interest, the research was used to focus the effort and produce results that can be made operational in the GCI at some point in the near future. The scope of Authentication and Single Sign-On was restricted to authentication only, but may include authorization in the future. The scope of Use Metrics was restricted to those metrics that do not, in any way, conflict with or jeopardize the privacy of GEOSS data users or their organizations. The scope of GEOSS Data-CORE Compatible Licenses was restricted to only those open access licenses and waivers identified by the GEO Data Sharing Working Group (DSWG) and approved by the GEO Plenary.

1.2 Activity key driversThe key driver for Authentication and Single Sign-On is to allow GEOSS Data Providers that require registration and login to participate in GEOSS without putting an undue burden on the GEOSS Data Users to register multiple times and execute the login process repeatedly when trying to discover and access GEOSS resources. Therefore, the goal of having a GEOSS-wide federation for single sign-on was established.

The key driver for Use Metrics is to gather information about GEOSS resources being discovered and accessed so that GEOSS Data Providers and GEO can gain knowledge as to the use and implied value of GEOSS resources. These metrics are viewed as essential feedback to the value of GEOSS.

The key driver for GEOSS Data-CORE Compatible Licenses is to support the GEOSS Data Providers that may have licenses associated with their resources, and who wish to have that licensing information be available to GEOSS users when they discover the licensed resources. The license information should be part of the metadata so that redistributions of the resources with the metadata will also make the licensing information available to the recipients of the redistributed resources.

1.3 Summary of AIP-6 effortsThe AIP-6 Data Sharing Guidelines Working Group (DSGWG) is responsible for the efforts related to User Authentication and Single Sign-On (SSO), Use Metrics, and GEOSS Data-CORE Compatible Licenses. These topics have each been identified as priority actions for 2013 by the GEO Infrastructure Implementation Board. Additionally, the Authentication and SSO effort, as well as the Use Metrics effort, have been identified as 2013 GEO Summit priorities. In addition to this AIP Engineering Report, the efforts of the AIP-6 DSGWG will result in contributions to data user and data provider guidelines and tutorials. These guidelines and tutorials will ultimately be published on the GEOSS Best Practices Wiki.

The work engaged in during AIP-6 enjoyed contributions by many individuals on behalf of many organizations. These efforts are captured in Table 1.

Table 1: AIP-6 DSGWG ContributorsName Area of Contribution AffiliationSteven F. Browdy SSO, Metrics, Licenses OMS Tech, Inc.; IEEEAndreas Matheus SSO Secure Dynamics; EC COBWEB

Page 6


ProjectGEO Data Sharing Working Group (DSWG)

Metrics, Licenses GEO DSWG

Siri Jodha Singh Khalsa Licenses NSIDC, GEO SIFAlva Couch SSO Tufts University, CUHASI

In particular, the AIP-6 DSGWG offers a special thanks to the European Commission’s FP-7 funded COBWEB project. COBWEB contributed greatly to the Authentication and SSO effort by establishing a proof-of-concept SSO federation and by assisting others in deploying the software necessary to join the COBWEB federation.

1.3.1 Results Summary

1.3.1.1 Authentication and SSOThe primary result is the establishment and demonstration of a SSO federation as a proof of concept. This federation was established by the COBWEB project and included both COBWEB participants, as well as some outside participants. The federation was established as a SAML-2 federation that accepts certain OpenID visitors outside the SAML-2 federation. This is accomplished via a trusted gateway that takes trusted OpenID visitors and allows them to be seen as SAML-2 users within the SAML-2 federation.

Of all the use cases to be realized for Authentication and SSO, most have been implemented. The use cases, identified for AIP-6, that still need to be implemented are:

Identification as "GEOSS User" During Registration

OpenID-Protected Data Access via SAML2 Authentication

1.3.1.2 Use MetricsThe use cases for this effort were written during AIP-6, and have been reviewed by the GEO DSWG. The DSWG also provided input regarding the specific metrics themselves. The agreed upon metrics do not capture any information related to identifying the individual GEOSS user or his associated organization. This is done to protect privacy. The fields of information to be collected are:

Data provider name

Dataset accessed

Date/time of access

"tags" were associated with the dataset (geossDataCore, geossAttribution, etc.)

License used for the dataset (N/A if none were used)

Cost to the GEOSS user for the dataset

Optional additional information

None of the use cases for Use Metrics were implemented during AIP-6 due to no AIP-6 participants volunteering to do this.

1.3.1.3 GEOSS Data-CORE Compatible LicensesThe licenses addressed during AIP-6 were identified for use by the DSWG and approved by the GEO Plenary. The licenses available to be used are just for GEOSS Data-CORE resources. This is due to the facts that the GEOSS Data-CORE only consists of registered resources that have no restrictions on use, and the current licenses and waivers accepted for use within GEOSS are targeted for open access, where no restrictions are allowed. The DSWG is currently working on a broader set of licenses that will handle more GEOSS Data Providers, specifically those that do not satisfy the requirements for the GEOSS Data-CORE.

The license fields currently defined to carry the licensing information about the resource will also be used for a

Page 7


broader set of licenses, but more fields may be added. These fields are:

License/waiver name - this will be a text field containing the common name of the license or waiver (CC0, CC-BY, etc.).

License pointer - this will be a URL field that links to the actual license or waiver.

License logo - this will be a URL field that links to a graphical logo for the license or waiver.

Attribution text - this will be a text field that contains the actual words to be used by users/applications for attribution.

The defined license fields need to be realized as metadata fields for the GEOSS Data Provider to populate. This will allow the licensing information to be exposed to GEOSS users visually, as well as programs that automate metadata processing. The metadata standards that currently have the above license fields mapped to them are ISO-19115 and Dublin Core. There are more metadata standards that still need to be addressed.

1.3.2 Recommendations SummaryThe following key recommendations are based upon the AIP-6 work completed by the DSGWG.

Recommendation 1: Continue developing Authentication and Single Sign-On so that all existing use cases are implemented, and so that the new ones are implemented to realize a GEOSS-wide SSO federation, including the necessary GCI components.

Recommendation 2: Expand Authentication and Single Sign-On so that authorization is handled along with authentication.

Recommendation 3: Develop a GCI component to control, manage, and store the Use Metrics information being provided by GEOSS Data Providers and the GCI, and to manage the reporting of Use Metrics to all interested.

Recommendation 4: Continue documenting the licensing metadata guidelines to handle the well-known metadata standards identified.

Recommendation 5: Work with the necessary GCI components to implement the recognition of the license information and its visibility to the GEOSS User.

Recommendation 6: Ensure that all guidelines and tutorials are published on the GEOSS Best Practices Wiki as soon as possible after completion of an activity. This will allow GEOSS Data Providers and GEOSS Users to learn more quickly about the evolution of GEOSS.

Page 8


1.4 Future workThere are always successes and challenges that result in major efforts. AIP-6 was successful at maintaining a high-level of participation in the plenary telecons. It also exhibited good leadership for all working groups and overall oversight. However, for some working groups, it is difficult to keep individual working group members engaged in their voluntary contributions, especially after the summer. It is also imperative to improve the education and outreach associated with AIP results. Most observers at the AIP results meeting during each annual Plenary week are AIP participants, where there ought to, instead, be a good number of people not involved in AIP. It is through the non-AIP observers that AIP results could more easily spread throughout all of the GEO tasks, committees, task forces, and other ad-hoc groups.

Page 9


2. Activity Background and ObjectivesThe GEO Data Sharing Working Group (DSWG), previously known as the Data Sharing Task Force, has developed a Data Sharing Action Plan1 and a set of Implementation Guidelines2 that reflect the GEOSS Data Sharing Principles3. These guidelines cover many areas. Those areas suggested as 2013 priorities by the Infrastructure Implementation Board, and to be covered in AIP-6, include authentication and single sign-on (SSO), GEOSS Data-CORE4 compatible licenses for access and use of data, and data access and use metrics. These areas of effort made initial progress in AIP-5, but were not completed.

Although GEOSS strongly encourages full and open exchange5 of data, there are inevitable instances where data providers will require user registration and adherence to certain data access conditions. User registration will involve user identification, authentication, and SSO, while licensing will involve those licenses compatible with the GEOSS Data-CORE. Data providers may require that the data accessed by data users be used in only certain ways. It is important to understand that for data made available through the GEOSS, and associated with licenses supported by the GEOSS Common Infrastructure (GCI), these licenses apply to, and travel with, the data only, not the service that provided the data.

The implementation of authentication and SSO, GEOSS Data-CORE compatible licenses, and data use metrics must satisfy the interoperability framework that is realized by the GCI. This will be captured in the Use Cases for each activity.

2.1 Authentication and SSO

2.1.1 BackgroundAlthough GEOSS strongly encourages full and open access to, and sharing of, data, there are inevitable instances where data providers will require user registration and login. This is the initial step in being able to perform authentication, authorization, and single sign-on (SSO). User registration is a way for data providers to accomplish two main goals: 1) control access to data, and 2) record information regarding the use of the data. In both cases, the mechanism used can be applied once or applied each time data access is requested. Since one of the goals of the GEOSS is to provide full and open exchange of data, minimizing the impact on data users to access and use data is a primary objective. A focus of AIP efforts is to have user registration required once, resulting in some kind of digital identification to be used repeatedly by the registered data user in a SSO scenario. This strategy may have an expiration date associated with the digital identification, requiring some sort of renewal process.

Within the GEOSS, SSO is an authentication model that allows a user to supply an identity token only once to successfully login to one or more services. To realize this authentication model, the GEOSS Web Portal or client application must be able to pass along an identity token for authentication by a GEOSS data provider, and GEOSS data providers must recognize when an identity token is received from another GEOSS data provider and honor it. This requires that data users must acquire an identity token and that data providers implement the means to perform

1 http://www.earthobservations.org/documents/geo_vii/07_GEOSS%20Data%20Sharing%20Action%20Plan%20Rev2.pdf

2http://www.earthobservations.org/documents/geo_vi/07_Implementation%20Guidelines%20for%20the%20GEOSS%20Data%20Sharing %20Principles%20Rev2.pdf3 http://www.earthobservations.org/geoss_dsp.shtml4 The GEOSS Data Collection of Open Resources for Everyone (GEOSS Data-CORE) is a distributed pool of documented datasets, contributed by the GEO community on the basis of full and open exchange (at no more than the cost of reproduction and distribution ) and unrestricted access.5 The expression “full and open exchange” means that data, metadata and products made available through the GEOSS are madeaccessible with minimal time delay and with as few restrictions as possible, on a nondiscriminatory basis, at minimum cost for nomore than the cost of reproduction and distribution.

Page 10

http://www.earthobservations.org/geoss_dsp.shtml

http://www.earthobservations.org/documents/geo_vi/07_Implementation%20Guidelines%20for%20the%20GEOSS%20Data%20Sharing%20Principles%20Rev2.pdf


http://www.earthobservations.org/documents/geo_vii/07_GEOSS%20Data%20Sharing%20Action%20Plan%20Rev2.pdf



authentication and pass the identity token to other GEOSS services, if necessary, to fulfill a GEOSS data request.

The intended management and implementation of GEOSS user authentication is via single sign-on. Some examples of open source solutions for this include OpenID and SAML-2. Suggestions for user registration, authentication, and SSO, as expressed by the GEO DSWG include:

Impose as light an impact as possible on the data providers and the GCI. GEOSS users should utilize an ID service, e.g. OpenID or Google. GEOSS users should be able to be identified as a “GEOSS User.” The GCI should not be responsible for holding or managing any personal user information.

Previous AIP efforts concluded that Shibboleth was too heavy a burden on data providers, so AIP-5 focused on OpenID only. OAuth was dropped from consideration since the focus was on authentication and not authorization. In AIP-6, in large part due to the participation of the COBWEB project, SAML-2 was added to the implementation plans for a GEOSS authentication and SSO solution. The GEOSS solution for authentication and SSO will be realized as a GEOSS-wide federation.

OpenID is an open and decentralized framework for authenticating users with the same digital identity on different web sites. There are many organizations offering OpenID provider services, but the ones that have been accepted as trusted services by the U.S. Government are Google and Verisign. Since the European Commission’s INSPIRE directive takes no position on trusted OpenID services, the current decision is to use the U.S. Government’s list as the basis for the GEOSS authentication and SSO solution.

Security Assertion Markup Language 2.0 (SAML-2) is a version of the SAML OASIS standard for exchanging authentication and authorization data between security domains. SAML-2 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, that is an identity provider, and a web service, that is a service provider. SAML-2 enables web-based authentication and authorization scenarios, including SSO.

2.1.2 ObjectivesThe objectives for AIP-6 with regards to user authentication and SSO are:

Finalize the use cases for a GEOSS-wide SSO federation based upon OpenID and SAML-2 authentication mechanisms. Establish a prototype SSO federation with the COBWEB project and other participants, demonstrating the developed use cases. Generate appropriate documentation to assist data providers in implementing SSO. Generate tutorial documentation for user registration, authentication, and SSO for placement in the Best Practices Wiki and distribution to data providers and data users. Produce a demonstration video, utilizing a prototype federation, exhibiting the feasibility of GEOSS SSO.

2.2 Use Metrics

2.2.1 BackgroundThe Data Sharing Principles Implementation Guidelines address use metrics. The GEOSS use metrics are agreed upon pieces of information that are collected during data discovery and access. This information can be provided by GEOSS Data Providers and by GCI components, such as the GEOSS Web Portal and the GEOSS Discovery and Access Broker, and centers around the particulars of what data is being accessed by GEOSS users. The metrics collected should be able to be enhanced from time to time, and should not include any user IDs, or any other information that compromises privacy for GEOSS users or their organizations.

It will be a suggested functionality for data providers to send the acquired metrics to the GCI. The actual metrics requested for the GCI, and the mechanisms employed by the data providers to gather and provide the recommended

Page 11


metrics to the GCI were initially addressed in use cases considered during AIP-5. The list of metrics to be gathered have been reviewed by the DSWG for appropriateness.

In order to differentiate between public access to a data provider’s resources and GEOSS user access to those resources, GEOSS users should be able to be identified as an official “GEOSS User.” The question then becomes, what is a GEOSS user? Since GEOSS users can access data from a data provider without utilizing the GCI, and in those situations they are just like the public, there are two ways in which a data provider can recognize a “GEOSS User.” One way is for the data provider to recognize a request for data via the GCI; e.g. the GEO DAB. The second way is if the data provide requires login, in which case the user can be identified as a “GEOSS User” via the GEOSS SSO federation. In the course of recognizing a user as a “GEOSS User,” the GCI should not be responsible for holding or managing any personal user information.

2.2.2 ObjectivesThe objectives for AIP-6 with regards to use metrics are:

Finalize the use cases for the gathering and reporting of the desired metrics. Finalize the initial set of information to be gathered and provided to the GCI. Recommend the implementation details of how to gather and report the use metrics. Generate appropriate documentation to assist data providers in implementing use metrics. Generate tutorial documentation for the Best Practices Wiki.

2.3 GEOSS Data-CORE Compatible Licenses

2.3.1 BackgroundData access and use conditions and restrictions require that data providers implement mechanisms that either actively control, or passively inform, how data is to be accessed and used. After careful consideration by the GEO DSWG, it was determined that initially the focus would be on a special collection of data resources that was largely full and open for data users. This concept was developed into the GEOSS Data Collection of Open Resources for Everyone (GEOSS Data-CORE). The definition of this collection is:

“The GEOSS Data Collection of Open Resources for Everyone (GEOSS Data-CORE) is a distributed pool of documented datasets, contributed by the GEO community on the basis of full and open exchange (at no more than the cost of reproduction and distribution ) and unrestricted access.”

It is also understood that the GEOSS Data-CORE is intended to address GEO Societal Benefit Areas. Further, the requirement from a data provider of (i) user registration, (ii) attribution of provider, and (iii) marginal cost recovery charges for access to the data are not considered restrictions in the context of the GEOSS Data-CORE. However, under plain language and in a formal legal sense, they would be viewed as restrictions.

In 2011, the GEO Data Sharing Task Force (DSTF), now known as the DSWG, worked on a Legal Interoperability paper (a summary is available6). The purpose of this paper was to address some legal approaches to sharing of data through the GEOSS Data -CORE. The Legal Interoperability paper focuses on the “legal interoperability” aspects of data made available through the GEOSS Data-CORE because it is essential for the effective sharing of data in GEOSS, which is a priority of the GEO Members. One may define legal interoperability for data as the compatibility of legal rights, terms, and conditions of databases from two or more sources so that the data may be combined and integrated by any user without further permission and without compromising the legal rights of any of the data sources used. Note that the concept of legal interoperability may be applied to the full range of openly available governmental, non-governmental, academic, and commercial data sets, however, the Legal Interoperability paper considers the concept only in the context of data resources that satisfy the GEOSS Data-CORE definition.

6 http://twiki.geoviqua.org/twiki/pub/AIP5/GEOSSDataCORELicenses/ GEOSS_Legal_Interoperability_Summary_20_Sept_2011.dox

Page 12

http://twiki.geoviqua.org/twiki/pub/AIP5/GEOSSDataCORELicenses/GEOSS_Legal_Interoperability_Summary_20_Sept_2011.dox

http://twiki.geoviqua.org/twiki/pub/AIP5/GEOSSDataCORELicenses/GEOSS_Legal_Interoperability_Summary_20_Sept_2011.dox


AIP-5 focused on licenses compatible with the GEOSS Data-CORE only, and how they could be utilized in GEOSS. Other types of licenses, and any general licensing framework, will be considered in the future. The consequence of this is that a data user, wishing to access and use non-GEOSS Data-CORE data, will need to make sure that any conditions or restrictions that the data provider has put on the access and use of the data are understood and followed. This is a data user responsibility and is not enforced or dealt with in any way by the GCI.

It is important to understand that for data made available through the GEOSS, and in particular, the GEOSS Data-CORE, any associated licenses supported by the GCI apply to, and travel with, the data only, not the service that provided the data. It is also acknowledged, as recommended by the DSWG, that open access licensing will not require active acknowledgement by the data user. Licenses will be assumed to be understood, acknowledged, and adhered to by the data user, including non-standard open access licenses once any needed negotiations have taken place.

2.3.2 ObjectivesThe objectives for AIP-6 with regards to GEOSS Data-CORE compatible licenses are:

Recommend the placement of license metadata in as many metadata standards as possible.

Test the discovery of these metadata in the GCI.

Generate appropriate documentation to assist data providers in implementing GEOSS Data-CORE compatible licenses. Generate tutorial documentation for the Best Practices Wiki.

Page 13


3. Authentication and Single Sign-On

3.1 SummaryAIP-6 commenced with OpenID being the only mechanism to be studied and tested for a GEOSS-wide authentication and SSO solution. The U.S. had many trusted OpenID services identified, and this was seen as a solution that had minimal impact on those data providers wishing to require registration and login. It was also decided that the focus would be on authentication only, not authorization. Since GEOSS is striving for full and open access to resources, authorization seems to suggest that there will be support for data providers to be discriminatory as to who is allowed to access certain resources.

One of the contributors to this effort in AIP-6 was the European FP-7 project called COBWEB. With their involvement, the SAML-2 protocol for authentication was proposed as another SSO solution in addition to OpenID. Since SAML-2 is a credential exchange protocol, it can be used with various user management systems to participate in a SSO federation. Together, OpenID and SAML-2 widen the potential participation for a GEOSS-wide SSO federation. COBWEB participation assisted other participants in this effort to get their SAML-2 operation working, which is greatly appreciated.

The implementation of authentication and SSO requires data providers and data users to implement the appropriate use cases described in Section 3.2, and modifications to certain GCI components will be necessary. Currently, the GCI components to be modified are the GEOSS Web Portal and the Discovery and Access Broker. The components that are modified or created to realize authentication and SSO for GEOSS are considered mediation components from the point of view of the GEOSS architecture. Specifically, they will be viewed as User Management components, utilizing the OpenID and SAML-2 interoperability arrangements and participating in the AIP Engineering Use Case categories identified as Visualize and Access (use case A4 ) and Maintain and Support (use case M4).

3.2 Use CasesThere are a number of use cases that have been identified for authentication and SSO. Each of these use cases has been discussed in detail and many have been reflected in the work done in AIP-6. The use cases will be presented here, after which will be a matrix showing which use cases have been implemented to date and which have not, along with appropriate comments.

Overview

Use Case ID UC-DSUA01

Title User Registration for Authentication via OpenID

Description This use case describes the process for creating an OpenID account at an OpenID Identity service, and receiving an OpenID identifier to be used for future login authentications requiring OpenID.

Actors and Interfaces

# OpenID Identity Service

# GEOSS Data User

Initial Status and Preconditions

The GEOSS data user has not yet acquired an identity token to be used for accessing data from GEOSS.

Basic Flow

Step 1: Data user utilizes browser to navigate to an appropriate OpenID Identity service for registration.

Step 2: Data user creates an OpenID account and provides identity information to the OpenID Identity registration service. One piece of information provided should be the text string geossUser, indicating this person is a GEOSS user (see use case UC-DSUA03). Data user must ensure that the identity attribute

Page 14


geossUser is retrievable for authentication purposes.

Step 3: Data user receives identification token from the OpenID Identity registration service; e.g. for www.myopenid.com, the identifier would be http:// yourusername.myopenid.com.

Step 4: Data user saves identification token for later use interactively and programmatically.

Post Condition

The data user is in possession of the OpenID authentication identifier token, and has saved it for future use with GEOSS data providers.

Overview

Use Case ID UC-DSUA02-1

Title User Registration for Authentication via SAML-2 as an OpenID User

Description This use case describes the process for allowing users with an OpenID account to participate in SAML-2 credential exchange for authentication. This can only occur if the OpenID account information is verified. One approach that can be taken is currently in place for those wishing to use the NASA NEX system with an OpenID account. In this case, the user must have an account created with NASA, which gets verified by the agency. After a successful verification, the OpenID account provided is linked with the created account at the NEX system. When using a SAML-2 based user credential exchange, this account creation and verification could take place at the Identity Provider. [see the uploaded attachment NEX_and_OpenID.pptx for more details.]



# GEOSS Data User

# Organization User Management System, e.g. NASA NEX User Management System


1. The user must have created an OpenID account.

2. An OpenID trust gateway must exist for the OpenID Identity server where the OpenID account was created.

Basic Flow

Step 1: Data user approaches the OpenID trust gateway to register his OpenID account for SAML-2 based credential exchange.

Step 2: The OpenID trust gateway provides a user registration form to the data user on behalf of the Organization User Management System.

Step 3: The data user fills out the registration form, i.e. supplies the requested information plus the OpenID account URI.

Step 4: The created user account is verified by the organization in charge of the OpenID trust gateway.

Step 5: The user account is verified positively.

Alternative Flow

Step 5.1: The user account is NOT verified positively.

Post Condition

Page 15

http://twiki.geoviqua.org/twiki/pub/AIP5/UserAuthentication/NEX_and_OpenID.pptx


After a successful verification of the data user identity, the data user's OpenID account can be used for all data providers that require SAML-2 based user credential exchange.

After an unsuccessful verification of the data user identity, the data user’s OpenID account cannot be used for any data provider that requires SAML-2 based user credential exchange.

Overview


Title User Registration for Authentication via SAML-2

Description This use case describes data users registering for SAML-2 based authentication. This process takes place through normal user management procedures in place at an organization. There is no self-registration available, as this does not ensure that the provided identity information is correct. Therefore, it is fundamental for SAML-2 based user registration that the organization creating the account has a procedure in place that ensures proper linking of an account with a human individual. The data user credentials are then made available to relying entities by the Identity Provider that is connected to the User Management System of the organization.


# Organization User Management System

# GEOSS Data User


1. The data user must have an account in the organization's user management system.

2. The data user’s organization's user management system must be connected with a SAML-2 Identity Provider.

Basic Flow

Step 1: Data user’s account gets enabled with the organization's Identity Provider.

Post Condition

The data user account can be used with all SAML-2 based data providers.

Overview


Title Identification as "GEOSS User" During Registration

Description This use case describes how a data user can identify themselves as a 'GEOSS User' for an OpenID account or a user management account from their organization. The 'GEOSS User' attribute would be made available as part of the user's authentication credentials when logging in.




# GEOSS Data User


The GEOSS data user has not yet associated the “GEOSS User” attribute with their authentication account.

Page 16


Basic Flow

Step 1: Data user navigates to the OpenID Identity registration service that was used, or is to be used, for creation of the OpenID account.

Step 2: Data user begins account registration or enters editing mode for an existing registered account.

Step 3: Once the data user gets to the page that allows the entry of personal or identity information for the account, the data user will enter the character string "geossUser" anywhere in the form that allows additional information beyond typical contact or name information.

Step 4: Data user ensures that the attribute “geossUser” that was entered is allowed to be provided as part of the data user’s identity when asked by an authentication process.

Step 5: Data user saves the entered information and logs out.

Alternate Flow

Step 1.1: Data user asks the SAML-2 Organization User Management System administrator to associate the character string “geossUser” with the data user’s user management account and to have it be included as an identity attribute during SAML-2 authentication credential exchange.

Post Condition

After execution of this use case, the data user will have an authentication attribute identifying them as a 'GEOSS USer.'

Overview


Title OpenID-Protected Data Access via OpenID Authentication

Description This use case describes how a data user, who is authenticating with OpenID, can access data that requires OpenID authentication.



# GEOSS Data User


The data user must have a valid OpenID account.

Basic Flow

Step 1: Data user navigates to a data provider’s site to access data resources.

Step 2: Data user provides the OpenID authentication identifier if asked for it; otherwise, data user has already logged in and the data provider’s site will challenge the veracity of data user’s identity using the authentication information provided by the data user’s browser or application.

Post Condition

After execution of this use case, the data user will have access to the desired data.

Overview


Page 17


Title SAML2-Protected Data Access via OpenID Authentication

Description This use case describes how a data user, who is authenticating with OpenID, can access data that requires SAML-2 authentication. It is, by default, not possible as the OpenID and SAML-2 protocols for user credential exchange are not interoperable. For data access where user account information is required to be exchanged via SAML-2, OpenID accounts cannot be used directly. The SAML-2 protected service must accept the OpenID Identity server as a trusted source. However, it is possible to provide SAML-2 based Identity Provider(s) for trusted OpenID Identity Provider(s). A SAML-2 based Identity Provider could act as a trusted mediator ensuring that only those OpenID accounts from trused OpenID providers can be used which are certified.



# Trust Gateway

# GEOSS Data User


1. The data user must have a valid OpenID account that can be successfully verified..

2. The OpenID Identity server used by the data user must be a trusted source to the Organization User Management System.

3. There must exist a Trust Gateway that can take a trusted OpenID data user and authenticate that user via SAML-2.

Basic Flow

Step 1: See use case UCDSUA07.

Post Condition


Overview


Title OpenID Protected Data Access via SAML-2 Authentication

Description This use case describes how a data user, who is authenticating with SAML-2 credentials, can access data that requires OpenID authentication. This requires SAML-2 users to be associated with OpenID accounts. The desire is to not require these users to have a separate OpenID account.



# Trust Gateway

# GEOSS Data User


1. The data user must have a valid OpenID account that can be successfully verified..

2. The OpenID Identity server used by the data user must be a trusted source to the Organization User Management System.

3. There must exist a Trust Gateway that can take a trusted OpenID data user and

Page 18


authenticate that user via SAML-2.

Basic Flow

Unknown at this time.

Post Condition


Overview


Title SAML2 Protected Data Access via SAML2 Authentication

Description This use case describes how a data user, who is authenticating with SAML-2 credentials, can access data that requires SAML-2 authentication. Data access requiring user credentials to be exchanged via SAML-2 with the user credentials available via an Organization User Management System SAML-2 Identity Provider is straight forward. A SAML-2 Service Provider receives user credentials from a SAML-2 based Identity Provider.


# Organization User Management System Identity Provider

# GEOSS Data User


The GEOSS data user has a user account with the Organization User Management System providing SAML-2 authentication credentials.

Basic Flow

Step 1: Data user approaches a SAML-2 data service provider and requests access to a protected resource for the first time.

Step 2: Data user credentials are requested from the organization's Identity Provider hosting the account.

Step 3: A session is created for the data user.

Step 4: The data user gets access to the requested resource based on access rights associated with the account.

Alternate Flow

Step 1.1: Data user, who already has an authenticated session, approaches a SAML-2 data service provider and requests access to a protected resource.

Step 1.2: The data user gets access to the requested resource based on access rights associated with the account.

Post Condition


Overview


Title Registering and Modifying a New Identity or Service Provider

Page 19


Description The concept of a federation based on SAML-2 user credential exchange requires a secure white listing of all entities participating in the federation. This white list is typically referred to as the "federation metadata", which is an XML file using the SAML-2 metadata structure that is time stamped and digitally signed to prevent fraudulent changes. This white list is periodically read by all entities of the federation; i.e. the Identity and Service Providers.

Because the correctness of this metadata file is important, it must be maintained by one member of the federation, typically called the coordination office. Whenever a new Identity Provider or Service Provider wants to become part of the federation and be entitled to use SAML-2 based user credential exchange, the coordination office must add the entity to the metadata file. This typically involves verification of service level agreements for Service Providers and review of the user management process for an Identity Provider.

Once the new party is added to the federation metadata, the file is time stamped and digitally signed again. After that, it is made available on a web server by the coordination office. Even though the federation metadata file is publicly available it is only useful to participating entities of the federation.


# Federation Coordination Office

# Identity Provider


1. The federation metadata file exists and is being maintained by the Federation Coordination Office.

2. An Identity Provider needs to be added to the federation metadata file or have its information modified.

Basic Flow


Post Condition

After execution of this use case, the federation metadata file will have been updated by the Federation Coordination Office, digitally signed, and made available again to the federation.

Page 20


The following table shows the state of the implementation of the authentication and SSO use cases after AIP-6.Use Case State of

ImplementationComments

UC-DSUA01: User Registration for Authentication via OpenID

Implemented Implemented by default, since this is an action undertaken by the GEOSS data user.

UC-DSUA02-1: User Registration for Authentication via SAML-2 as an OpenID User

Not Implemented There are various ways to go about this, but it is somewhat dependent on use case UC-DSUA06.

UC-DSUA02-2: User Registration for Authentication via SAML-2

Implemented Implemented by default, since the organization’s user management system and its administrator handle this.

UC-DSUA03: Identification as "GEOSS User" During Registration

Questionable This identity attribute was hard-coded in to prove the feasibility of use case UC-DSUA05, but has not been tested in a dynamic automated manner.

UC-DSUA04: OpenID-Protected Data Access via OpenID Authentication

Implemented This is implemented by default, since it is how OpenID works.

UC-DSUA05: SAML2-Protected Data Access via OpenID Authentication

Implemented

UC-DSUA06: OpenID Protected Data Access via SAML-2 Authentication

Not Implemented This needs more research, as there are differing opinions about its viability.

UC-DSUA07: SAML2 Protected Data Access via SAML2 Authentication

Implemented

UC-DSUA08: Registering and Modifying a New Identity or Service Provider

Questionable This is normally a manual process, but there needs to be investigation into automating this to support a GEOSS-wide federation.

3.3 Trust GatewaysIn order to have a GEOSS-wide federation for authentication and SSO, there must be mechanisms in place to allow for:

Authentication across organizational federation boundaries Authentication between different authentication protocols

A Trust Gateway is a mechanism that allows different protocols and cross-boundary resource access to successfully work. In AIP-6, a Trust Gateway was used with the COBWEB federation to allow OpenID users to “join” the COBWEB SAML-2 federation and access resources provided by COBWEB federation members. Trust Gateways allow the augmentation of existing federations to support a larger federation by including more participants as “trusted” users.

The Trust Gateway implemented in AIP-6 for the COBWEB federation was provided by the University of Edinburgh. This work is documented in the Trust Gateway Documentation7 paper. The contents of this paper state:

7 http://twiki.geoviqua.org/twiki/pub/AIP6/UserAuthSSOAIP6/2013-11-11_trust_gateway_documentation.docx

Page 21


SAML federations typically contain Service Providers (SPs) or Identity Providers (IdPs). In a SAML federation, a user is only required to provide credentials to their own IdP. The home organization IdP typically connects to a local identity management system (for example, Active Directory) for the authentication. The credentials are not passed to any other entity in the federation.

Metadata from eligible IdPs or SPs is aggregated with the existing members’ metadata by a trusted federation operator, and published. In the case of the AIP-6 Access Management Federation, the metadata aggregator and publisher is EDINA, based at the University of Edinburgh.

When a user tries to access a protected web resource on a SP, they are asked to choose which IdP they have an account on, and the web browser is re-directed to that IdP. After successfully checking the user’s credentials, this IdP releases a set of attributes derived from that user’s identity to the SP. In the AIP-6 federation, an attribute of GEOSS:user is set to “organizational” to indicate that the user has been authenticated at a SAML IdP.

A social identity provider that uses OpenID cannot be directly included in a SAML federation. Instead, a SAML IdP is used as a trusted gateway. When accessing a SAML-protected resource, the user is asked to choose their identity provider and, in this case, they choose the “Google OpenID to COBWEB gateway”.

This SAML IdP then acts as an intermediary and redirects the user to the social ID provider. The user logs on to the social ID site as normal and that social ID provider releases attributes to the gateway confirming authentication. Neither the username nor the password are passed to the gateway or to any other servers in the federation. The gateway receives the user attributes from the social ID provider, derives SAML attributes for the AIP-6 federation, and releases those attributes to a service provider.

In this case, the gateway adds a new attribute GEOSS:user with a value of “social” to indicate that the user has been authenticated at a social identity provider.

A diagram that illustrates the procedure for using the Trust Gateway implemented by the University of Edinburgh for AIP-6 is shown in Figure 2.

3.4 Test ImplementationsDuring AIP-6, the goal was to realize an authentication and SSO federation that implemented as many of the identified use cases as possible. In this regard, a prototype SSO federation was implemented by the COBWEB project, as illustrated in Figure 1. The participants are named in the diagram.

The main area of concern for the implementation of a GEOSS-wide SSO federation is the amount of effort that data providers, or their organizations, will need to take to join the federation, and this translates into Trust Gateways. Although, it will be necessary to have Trust Gateways that work in both directions, OpenID SAML-2 and SAML-2 OpenID, some of the details that were documented by the University of Edinburgh for the OpenID SAML-2 are as follows:

We have chosen simpleSAMLphp (http://simplesamlphp.org/) to implement the gateway, as it includes a bridge between OpenID and SAML protocols. The installation instructions for simpleSAMLphp assume a Debian Lenny linux distribution. As EDINA (University of Edinburgh) runs a virtualized infrastructure of RedHat, several modifications were required. A list of pre-requisites is:

o Installed PHP

Page 22

http://simplesamlphp.org/


o Installed many XML handling and cryptographic dependencies for PHP, including a C compiler to build the appropriate modules

o Configuration to be an OpenID consumer from Google is included in the standard distribution; we uncommented the config options

o The GEOSS:user attribute is added to all users that successfully authenticate at Google; a straightforward configuration change

o Installed php-pecl-memcache, configured memcache. Configured system to automatically start memcached (similar to httpd)

o Edited simpleSAMLphp config file to use memcache o Configured software to use SAML2 Artifact profile

http://simplesamlphp.org/docs/stable/simplesamlphp-artifact-idpo Added browser-facing certificate in entity’s metadata since the trust fabric of the AIP-6 federation

is maintained through directly-embedded keys only.

Figure 1: Prototype SSO Federation for GEOSS

This diagram exhibits the SSO federation implemented by COBWEB in support of AIP-6 efforts. The participants in the federation could participate with any combination of being a data provider (called a service provider in the diagram), an identity provider for the authentication, a discovery service, or a trust gateway for OpenID. This federation, by default, uses SAML-2 as an authentication and SSO solution. In order for an OpenID user to gain access to this federation, the user’s authentication credentials must be validated through a trust gateway. This happens if the OpenID user has an identity attribute as a “GEOSS User.”

Page 23

http://simplesamlphp.org/docs/stable/simplesamlphp-artifact-idp


3.5 Results and Next Steps (conclusions and recommendations)From a use case perspective, there were 9 use cases identified for implementation. Of those, 5 were successfully implemented, 2 were not fully implemented, but have no impediments to implementation, and 2 were not implemented. The authentication and SSO federation that was setup by COBWEB was demonstrated and worked as expected.

Through the prototype federation that COBWEB instantiated, there has been success with a single SAML-2 federation that also allows trusted OpenID users SSO access. OpenID access to a SAML-2 federation is achieved via a trusted gateway. This was successfully demonstrated for the COBWEB federation by the University of Edinburgh. However, in order to support a GEOSS-wide SSO federation, there must be a trusted relationship between different federations supporting SAML-2. This is a new use case that must be investigated.

The successes of AIP-6 for SSO are centered about the data users interactively requesting and gaining access to data resources that require user login. It is a requirement that gaining access to data resources registered with GEOSS must also be able to occur programmatically, where there are no interactive users. Therefore, the GEOSS-wide SSO federation must also handle this situation.

Some open questions are: In the AIP-6 SSO federation, any user that authenticates at a federation IdP or with a Google account is allowed access to the application data. In the future, it will be necessary to investigate how to allow authorization to specific users. Which attributes from the Google OpenID provider can be passed to a SAML federation through the trust gateway is unknown. It may be that it is not possible to pass attributes through the gateway, but can still generate persistent SAML attributes that are suitable for the application. The staff at EDINA, at the University of Edinburgh, have the most experience with Shibboleth software, and have deployed the Shibboleth Metadata Aggregator to collate the federation metadata. Maintaining a simpleSAMLphp gateway is outside of their core competence.

The recommended next steps for this activity include: Finishing the use cases that were not fully implemented. Researching and implementing a new use case with respect to multiple SAML-2 federations being able to interoperate for authentication and SSO purposes. Researching and implementing a new use case with respect to programmatic authentication and SSO. To integrate the GEO DAB and GEOSS Web Portal as GCI components participating in the federation as clients accessing data. Consider the open questions mentioned above with respect to the requirements of a GEOSS-wide SSO federation. Extending the capabilities of the federation by supporting authorization. Generating the appropriate documentation and tutorials needed to inform and educate the data providers and data users with regards to participating in the GEOSS SSO federation.

Page 24


Figure 2: Authentication Flowchart for AIP-6

Page 25


4. Use Metrics

4.1 SummarySince there were no participants in AIP-6 for implementing the work done in AIP-5, AIP-6 efforts were focused on shoring up the details of the use cases and reconnecting with the DSWG for current feedback. The goals remain the same as for AIP-5. The current list of desired metrics includes:

Data provider name Dataset accessed Date/time of access Tags associated with the accessed data (geossDataCore, geossAttribution, etc.) License associated with the accessed data Cost associated with the accessed data Optional additional information

A request was made to the DSWG to provide input to refine or modify this list, and to specify important requests regarding metrics. The input received that could have impacts on how use metrics are dealt with, and responses, is as follows:

Request: It is absolutely necessary to stay away from collecting any personal identifying information, whether it is a person, agency, company, etc. Identifying individual users, natural persons and business entities like corporations, is illegal in a number of jurisdictions and, depending on how the identifying data is used, it could be expected to result in lawsuits. This is a sensitive issue and requires careful treatment.

Response: This request has already been accepted.

Request: Provide the non-specific location of the user as a metric. This could include country, region, etc.

Response: This added field is very possible, but it would have to be determined to what level of location granularity still protects the identity of the user. This information can be retrieved from the IP address, although it is not perfect information. In implementing this, the IP address itself cannot be reported as a metric.

Request: Consider introducing a broad categorization of providers that could be collected for metrics; e.g. research, non-profit/NGO, public sector, private sector (small, medium, large), etc.

Response: This categorization, used in order to better identify the type of data provider, can be easily implemented, and will be developed and added to the list of metrics collected.

Request: Consider tracking the intended use or reuse of the data, such as for societal benefit (which SBA).

Response: This does not seem possible, since data users cannot be expected to answer these questions every time data is accessed. The use metrics, currently, are not about the user, but the data.

Request: Data becomes more valuable the more it is re-used. It would be interesting to track the re-use, if possible.

Page 26


Response: Since re-use will normally occur outside of the GCI and GEOSS, it will not be possible to track re-use. There will not be a trail of users kept for a data resource, which makes tracking re-use impossible, unless there is a volunteer capability for users to report to the use metrics component what data they are using, and where they accessed it from.

Request: Track the metrics information by leveraging the metadata records of the data, where applicable.

Response: Reading use metrics from the metadata and other means is quite possible for most metrics desired. This makes it possible for the GCI components to provide the metrics. When data is accessed from outside the GCI, the data provider will have to report the metrics. Since duplicate reporting is undesirable, there needs to be a way to differentiate between GCI access to a data resource and non-GCI access to a data resource.

Request: There is a need to collect use metrics for GEOSS Data-CORE data, regardless of whether users who access the data are nominally coming from GEOSS or not. It seems that it would be valuable to understand how many users will actually access data contributed to the GEOSS Data-CORE (and tagged as such), even if they didn't get to that data through the GEOSS Web Portal or other GEOSS interface.

Response: Tracking GEOSS Data-CORE use, regardless of whether the user is from GEOSS or not, is quite possible. This can be implemented within the metrics reporting instructions to the data providers.

Request: It is prudent to design metrics to address the "contradictions." Accurate results derived from metrics can be used to further promote openness. If the metrics demonstrate which data providers are more open than others, that information can be used to increase peer pressure to share. In the end, peer pressure is the only true enforcement in a voluntary organization.

Response: This would be realized through use metrics reporting, where the report is run against data providers. The problem is that the use metrics component will only know about those data providers that already are willing to share data. This request does not seem practical unless all data providers to GEOSS were known a priori and configured into the use metrics component, along with the data resources they were sharing.

4.2 Use CasesThe use cases developed for the gathering and reporting of use metrics are very general and broad, leaving the details to the software specification of the use metrics component that needs to be written and deployed. The use cases deal with metrics generated from data access and not data discovery. Data discovery metrics are difficult, since a given data resource can be a member of a search result even though it is not a target of the user. It has been argued that data discovery metrics allow data providers to understand the value of GEOSS for their data resources, but it is believed that this value can also be gleaned from the metrics of data access.

The use metrics are more meaningful when it is known that a GEOSS user is accessing the data. This can only be reliably accomplished if a user can be tracked as a “GEOSS User.” This will be possible for data providers if they require registration and login, since the GEOSS SSO federation will have a “GEOSS User” attribute associated with users. However, in a non-login situation, it is necessary to find a manner in which to “tag” the user as a GEOSS user. When the GCI is used to access the data, the data provider can be told that the access is for a GEOSS user, but not all access is via the GCI.

No use cases have been implemented yet due to certain non-participation in AIP-6.

Overview

Page 27


Use Case ID UC-DSUM01

Title Data Provider or GEO Secretariat Accesses and Uses Metrics

Description Any data provider or someone from the GEO Secretariat can query the use metrics component for a report on various aspects of the use metrics data collected.


# Data Provider

# GEO Secretariat

# Use Metrics Component


1. The Use Metrics Component is deployed and operational.

2. Actors wishing to query the Use Metrics Component have registered for login, if necessary.

Basic Flow

Step 1: Data Provider or GEO Secretariat login to gain access to the Use Metrics Component.

Step 2: Query parameters are entered into a query form.

Step 3: Query is submitted for processing.

Step 4: The report output from the query is presented in HTML.

Post Condition

After execution of this use case, the data provider or the GEO Secretariat will be able to view the report queried for. The Use Metrics Component will be ready to process another query.

Overview


Title Data Provider Submits Use Metrics to the Use Metrics Component

Description Data Provider invokes the use metrics web service to pass use metrics data to the Use Metrics Component. The fields of information collected are sent in either aggregated or non-aggregated form. Data Provider can invoke this service in real-time, daily, weekly, etc. as is desired.


# Data Provider




2. Data Providers wishing to report metrics to the Use Metrics Component have registered for login, if necessary.

Basic Flow

Step 1: Data Provider will invoke the Use Metrics Component service with authentication information and metrics information.

Step 2: Use Metrics Component will process the reported information and send back to the Data Provider a result code.

Step 3: Data Provider will either resend the information in the case of an error, or handle the successful result code in a proprietary manner.

Page 28


Post Condition

After execution of this use case, the Use Metrics Component will be updated with new metrics data from the data provider.

Overview


Title Data Provider Resubmits Use Metrics to the Use Metrics Component

Description Data Provider invokes the use metrics web service to pass use metrics data to the Use Metrics Component as an update to an already submitted report of metrics. The fields of information collected are sent in the format used previously.


# Data Provider




2. Data Providers wishing to resubmit metrics to the Use Metrics Component have a particular submission to update that was already submitted previously.

Basic Flow

Step 1: Data Provider will invoke the Use Metrics Component service with authentication information and metrics information, along with an identifier that identifies the previous report being updated.

Step 2: Use Metrics Component will process the reported information and send back to the Data Provider a result code.

Step 3: Data Provider will either resend the information in the case of an error, or handle the successful result code in a proprietary manner.

Post Condition

After execution of this use case, the Use Metrics Component will be updated with resubmitted metrics data from the data provider.

Overview


Title Analyze GEOSS Data-CORE Use from the Metrics

Description From the use metrics provided by the data providers and GCI components, a query will be executed by the Use Metrics Component to analyze all submitted information with respect to GEOSS Data-CORE usage. After analysis, an appropriate report will be generated. This analysis can be initiated by the GEO Secretariat or a data provider.



# GEO Secretariat

# Data Provider

Initial Status and


Page 29


Preconditions 2. The GEO Secretariat or Data Providers wishing to analyze the use of GEOSS Data-CORE have registered for login, if necessary.

Basic Flow

Step 1: Data Provider or GEO Secretariat login to gain access to the Use Metrics Component.

Step 2: A request to execute an analysis of GEOSS Data-CORE usage is initiated by the GEO Secretariat or Data Provider.

Step 3: The Use Metrics Component executes the requested analysis against all submitted metrics for the desired timeframe.

Step 4: The report output from the analysis is presented in HTML.

Post Condition

After execution of this use case, the data provider or the GEO Secretariat will be able to view the analysis report executed. The Use Metrics Component will be ready to service another request.

Overview


Title Analyze Societal Benefit Area Use from the Metrics

Description From the use metrics provided by the data providers and GCI components, a query will be executed by the Use Metrics Component to analyze all submitted information with respect to GEOSS SBA usage. After analysis, an appropriate report will be generated. This analysis can be initiated by the GEO Secretariat or a data provider.



# GEO Secretariat

# Data Provider



2. The GEO Secretariat or Data Providers wishing to analyze the use of GEOSS SBA resources have registered for login, if necessary.

Basic Flow


Post Condition

After execution of this use case, the data provider or the GEO Secretariat will be able to view the analysis report executed. The Use Metrics Component will be ready to service another request.

4.3 Implementation Scenarios and Web ServicesThe implementation of the Use Cases are dependent on the implementation and deployment options available for the use metrics component, and the relative burden that the strategy for use metrics puts on the GCI and the data providers. The goal is to have the burden on the data providers be as light as possible, while knowing that there will be some burden. This is due to the fact that, generally speaking, the data providers are uniquely positioned to report the metrics about their own data resources.

Page 30


The impact on the GCI will be determined partly by who implements the use metrics component, and where it is deployed. The minimum impact on the GCI will be the requirement for the GEO DAB and the GEOSS Web Portal to report appropriate metrics to the use metrics component. If the use metrics component is developed and deployed as part of the GCI, then there will be additional burdens on the GCI due to the fact that there is a new component in the GCI. These burdens will include an update to the GCI Consolidated Requirements and a commitment for continued operations management from an organization responsible for the use metrics component.

Currently, there are two alternatives for the deployment of a use metrics component. The first alternative is as a new GCI component. This will require that an organization wishing to implement this component work within AIP to develop it and test it before going operational. A request for such an organization was written into the AIP-5 and AIP-6 Call for Participation, but there were no contributors agreeing to take this activity. The other alternative for the deployment of a use metrics component is for the GEO Secretariat to take on the responsibility of developing this component as a GEO tool, and making it available to capture and report the use metrics coming from the data providers and certain GCI components. See Figure 2.

4.4 Test ImplementationsTesting the gathering and reporting of the desired use metrics requires that component software be written to realize the use cases already developed. This component, as described in Section 4.3, would allow data providers and appropriate GCI components to send use metrics to this component, and allow for the querying and reporting of the results of gathering use metrics.

Unfortunately, for AIP-6, no test implementations were possible. Although there was a request written into the AIP-6 Call for Participation, there was no group or organization that responded willing to implement the component software necessary for testing the use cases for use metrics.

4.5 Results and Next Steps (conclusions and recommendations)During AIP-6, the use metrics effort was only able to gain more feedback from the DSWG and to make more concrete the use cases and associated implementation alternatives. More could not be accomplished due to the fact that no organization responded to the AIP-6 Call for Participation with regards to use metrics. Therefore, actual implementation efforts did not occur, and, consequently, no testing of the concept of use metrics took place.

The DSWG has indicated many desirable functionalities that it would like to have made available via the use metrics component. They are categorized by General, GEOSS User, GEOSS National Member, and GCI.

General Use metrics should be open to the public. Data providers should be allowed to verify their submissions to the use metrics component, and to resubmit metrics data, if necessary. There may need to be a registration step to allow this. The regularity of metrics submission should be decided by the data provider. It can be real-time or periodic. The data provider can choose the period, including daily, weekly, monthly, quarterly, etc. The data provider can also decide whether the metrics data sent to the use metrics component is aggregated or not. There should be quarterly and annual statistics on the types of uses (e.g., primary SBA) and category of user for registered GEOSS users who accessed or downloaded data. This may be difficult to provide.

GEOSS User A registered GEOSS user should be able to get summary statistics on his/her order history over the past year, including:

o Monthly statistics on data accesses and volume downloaded in total and by data provider and by GEOSS Data CORE tags.

o Monthly statistics on the number of OGC-compliant requests made through registered GEOSS clients (assuming the user registered with the client).

Page 31


Figure 3: Use Metrics Component Deployment Strategy

This diagram shows the potential deployment arrangement for the use metrics component. This component will expose one or more services that will allow the use cases to be implemented. Whether this component exists as a new GCI component or a GEO tool, it will capture metrics from the data providers, the app providers, and the GCI in an effort to demonstrate the value that GEOSS offers to its providers and users. GCI components provide metrics, but do not query for reports. Data providers and app providers provide metrics, and can query for reports. The GEO secretariat can also query for reports.

GEOSS National Member A GEOSS national member may wish to assess the overall impact of GEOSS on its data providers and its data users. It therefore should be able to obtain the following metrics from its own providers and/or from the GCI:

o Quarterly statistics on the number of queries from the GCI search interface to a specified set of GEOSS data providers (i.e., those within its jurisdiction).

o Quarterly statistics on the data accesses and downloads by all registered GEOSS users to the specified set of GEOSS data providers, total and by GEOSS Data CORE tags.

o Quarterly statistics on the number of OGC-compliant requests from registered GEOSS clients to

Page 32

GEO DAB GWP

Data Provider

App Provider

Data Provider

App Provider

GCI / GEOSec Component

Use Metrics Service


the OGC-compliant services maintained by the specified set of GEOSS data providers, and the volume of results delivered in response.

o Quarterly and annual statistics on the types of uses (e.g., primary SBA) and category of user for registered GEOSS users who accessed or downloaded data from the specified set of GEOSS data providers. This may be difficult to achieve.

o Quarterly statistics on the data accessed and volume downloaded in total by registered GEOSS users known to be affiliated with the national member, total and by GEOSS Data CORE tags. This may be difficult to achieve.

o Quarterly statistics on the number of OGC-compliant requests made through registered GEOSS clients by registered GEOSS users known to be affiliated with the national member. This may be difficult to achieve.

GCI The GCI wishes to assess the overall impact of GEOSS on its data providers and data users and provide specific summaries on request to key stakeholders. It therefore desires to obtain the following metrics from the GCI and/or from data providers:

o Monthly, quarterly, and annual statistics on the number of queries from the GCI search interface by GEOSS data provider.

o Monthly, quarterly, and annual statistics on data accesses and downloads by registered GEOSS users (total and by user category/type and by NMO/PO affiliation if available) by GEOSS data provider (total and individual) and by GEOSS Data CORE tags.

o Monthly, quarterly, and annual statistics on the number of OGC-compliant requests from registered GEOSS clients (total and by registered GEOSS users) to the OGC-compliant services maintained by GEOSS data providers (total and individual), and the volume of results delivered in response.

o Quarterly and annual statistics on the types of uses (e.g., primary SBA) and category of user for registered GEOSS users who accessed or downloaded data from GEOSS data providers. This may be difficult to achieve.

The recommended next steps, in addition to consideration of the above desires from the DSWG, for use metrics are: Implement and deploy the use metrics component for testing. This can either be through AIP-7 or through a GEO Secretariat effort. Generate tutorial documentation regarding user metrics for placement in the Best Practices Wiki and distribution to data providers. Generate guidance documents for data providers regarding how to implement use metrics. Collaborate with the GEO DAB and the GEOSS Web Portal to make sure that appropriate use metrics are being sent to the use metrics component.

Page 33


5. GEOSS Data-CORE Compatible Licenses

5.1 SummaryFor the GEOSS Data-CORE, only passive mechanisms are considered for use in realizing the implementation of appropriate licenses. The mechanism chosen to be used is metadata. The population of a data provider’s metadata with information related to GEOSS Data-CORE compatible licenses includes:

License/waiver name - this will be a text field containing the common name of the license or waiver (CC0, CC-BY, etc.). License pointer - this will be a URL field that links to the actual license or waiver. License logo - this will be a URL field that links to a graphical logo for the license or waiver. Attribution text - this will be a text field that contains the actual words to be used by users/applications for attribution.

This information, if put into the metadata, can be discovered and made known to the data user so that the data user is made aware of any conditions that travel with the data of interest to the user.

5.2 Use of Metadata Standards and Metadata FieldsIn the implementation plans for licensing, many of the GCI components will likely be impacted, as well as the metadata population suggestions for data providers. The metadata will be used to hold the appropriate fields of information related to the data waivers and licenses used. The plan is to support as many metadata standards as possible for the encoding of GEOSS Data-CORE compatible licenses. The planned metadata standards include:

ISO 19115/19139 Dublin Core OpenSearch WCS, WFS, WMS, WPS, SOS GBIF THREDDS UNICODE-UTF8 NetCDF GCMD DIF

For AIP-6, the only metadata standard used to illustrate population of metadata fields with license information was ISO 19115. The metadata fields recommended for population with ISO 19115-1 (the revsion of 19115:2003 that is currently in Draft International Standard stage) are:

License/waiver name: MD_Contstraint > CI_Citation > title License pointer: MD_Contstraint > CI_Citation > onlineResource License logo: MD_Contstraint > graphic Attribution text: MD_Contstraint > useLimitation

It is further suggested that an ISO 19115-1 element be added stating that the constraint is a license and not something else, such as a patent or copyright. To realize this , the following element should be populated:

MD_Metadata / MD_Constraints / MD_LegalConstraints > useConstraints = licenseUnrestricted (or whatever is appropriate from the RestrictionCode codelist)

5.3 Use Cases

GEO Portal Use Cases Involving Data Licenses

Page 34


These use cases describe the situations when a data consumer uses the GEO Portal to discover data sets based upon the license information associated with the data. The GEO Portal will have implemented the use of license symbols to allow a data consumer to easily specify or recognize data license conditions in preparation for searching or accessing data via GEOSS. The symbols to be used are those shown in Table X.

Overview

Title GEOSS Data Consumer Performs Data Search Using Data License Conditions

Description This use case covers the use of the GEO Portal to search for data sets satisfying specific license conditions chosen by the data consumer.


# GEO Portal

# GEOSS Data Consumer


# Service Providers have registered services in the CSR, including, when applicable, license information for the data associated with the service.

# The Clearinghouse has harvested the CSR and has metadata containing available license information for Service Providers’ data.

# The GEO Portal supports data searches via license type.

Basic Flow

Step 1: Data consumer chooses data license types, along with other search criteria.

Step 2: Data consumer begins the search.

Step 3: The GEO Portal finds all records satisfying the search criteria, including the license types specified by the data consumer, and displays them for the user. The display also makes visible the icons used for the data licenses associated with each displayed data set.

Post Condition

The data consumer has a search result to view all data sets found satisfy the licensing criteria specified.

Overview

Title GEOSS Data Consumer Makes Data Access Decision Using Data License Conditions

Description This use case covers the use of the GEO Portal to assist the data consumer in deciding which data sets to access by including license information in the results of the search conducted by the data consumer.


# GEO Portal



# Service Providers have registered services in the CSR, including, when applicable, license information for the data associated with the service.

# The Clearinghouse has harvested the CSR and has metadata containing available license information for Service Providers’ data.

# The GEO Portal supports data searches via license type and access to license description.

Basic Flow

Step 1: Data consumer performs a data search without specifying license types.

Page 35


Step 2: Data consumer begins the search.

Step 3: The GEO Portal finds all records satisfying the search criteria and displays them for the user. The display also makes visible the icons used for the data licenses associated with each displayed data set.

Step 4: The data consumer clicks on license icons to navigate to the text of the license. This allows the user to read what the license conditions are.

Step 5: Data consumer chooses which data set to access.

Step 6: If the chosen data set has no associated data license, then the GEO Portal notifies the data consumer that data access is not possible.

Post Condition

The data consumer can view the license conditions associated with each data set in the search results, and can read the text of the license, if necessary. The data consumer is in a position to make an informed access to data.

Use Case for Programmatic Access to Data Carrying a License

This use case describes the situation where an application or system will access a data set that carries a license. The decision as to which data set will be accessed has already been made. It will be known, at the time of access, whether the data set has a license attached to it, and which type.

Overview

Title Programmatic Access to License Carrying Data

Description This use case covers an application or system programmatically accessing data via a GEOSS-registered data service where licensing conditions exist. The licensing conditions will be found in the metadata.


# Data Consumer Application or System

# Data Service

# Data Consumer


# Data Provider has appropriate metadata that contains license information, if applicable.

# The data consumer is aware of any licensing conditions attached to the data set to be accessed, and has completed any negotiations necessary.

# The data consumer application or system is aware of the licensing conditions attached to the data set to be accessed.

Basic Flow

Step 1: Data consumer’s application or system interoperates with the appropriate data service to retrieve data.

Step 2: If not part of the data in Step 1, the data consumer’s application or system interoperates with the data service to access and retrieve the metadata associated with the data from Step 1.

Step 3: Data consumer’s application or system verifies that the licensing conditions in the metadata match the licensing conditions expected. This includes attribution information, if applicable to the license used.

Page 36


Step 4: If licensing conditions are validated, including a check for a non-existent license, then the application or system continues execution as expected; otherwise, execution related to the accessed data halts and the data consumer is notified of a licensing issue to be rectified.

Post Condition

The data consumer’s application or system has successfully retrieved the data and metadata, and has tested the validity of the license conditions attached to the data. The state of execution of the data consumer’s application or system reflects the license check. The data consumer has been notified if there is a licensing problem.

Use Cases for GEO Portal Access to Multiple Data Sets

These use cases describe the situations where the data consumer chooses to access multiple data sets through the GEO Portal for the purpose of creating a merged data set or a derived data product. The decision as to which data sets will be accessed will have already been made. It will be known, at the time of access, whether the data sets have licenses attached to them, and which types.

Overview

Title GEOSS Data Consumer Accesses Multiple Data Sets Through GEO Portal Using Standardized Open Access Data Licenses

Description This use case covers the use of the GEO Portal, by a data consumer, to retrieve multiple data sets for the purpose of creating a merged data set or a derived data product. All data sets accessed will have standardized open access licenses associated with them.


# GEO Portal



# Data Consumer has conducted a search to determine which data sets to retrieve.

# Data Consumer is knowledgable of the various licenses associated with the data sets to be retrieved.

# The GEO Portal supports the generation of metadata for retrieved data sets where merged records or derived data products will result.

Basic Flow

Step 1: Data consumer commences the access of data from multiple data sets simultaneously.

Step 2: GEO Portal retrieves the various data sets.

Step 3: GEO Portal accesses the metadata for all data sets retrieved, and isolates licensing conditions for analysis.

Step 4: GEO Portal takes all license conditions and determines the collective license to be associated with the merged data or data product.

Step 5: GEO Portal takes all attributions and generates new attribution metadata to reflect the merged data or data product.

Step 6: GEO Portal generates metadata for merged data or data product that reflects the new licensing conditions and attribution,

Step 7: GEO Portal makes merged data set or derived data product available to the data consumer.

Page 37


Post Condition

The data consumer has access to a merged data set or derived data product with appropriate metadata to accurately reflect licensing and attribution.

Overview

Title GEOSS Data Consumer Accesses Multiple Data Sets Through GEO Portal Using a Non-Standardized Open Access Data License or No License

Description This use case covers the use of the GEO Portal, by a data consumer, to retrieve multiple data sets for the purpose of creating a merged data set or a derived data product. At least one of the data sets accessed will have a non-standardized open access license associated with it or no data license associated with it.


# GEO Portal



# Data Consumer has conducted a search to determine which data sets to retrieve.

# Data Consumer is knowledgable of the various licenses associated with the data sets to be retrieved, and has completed negotiations as necessary.

# The GEO Portal supports the generation of metadata for retrieved data sets where merged records or derived data products will result.

Basic Flow

Step 1: Data consumer commences the access of data from multiple data sets simultaneously.

Step 2: Data consumer is notified by the GEO Portal if any data sets to be accessed carries no data license. In this case, no retrieval is possible, the data consumer must adjust the data access request, and start over at Step 1.

Step 3: GEO Portal retrieves the various data sets.

Step 4: GEO Portal accesses the metadata for all data sets retrieved, and isolates licensing conditions for analysis.

Step 5: GEO Portal takes all license conditions and determines the collective license to be associated with the merged data or data product.

Step 6: GEO Portal takes all attributions and generates new attribution metadata to reflect the merged data or data product.

Step 7: GEO Portal generates metadata for merged data or data product that reflects the new licensing conditions and attribution,

Step 8: GEO Portal makes merged data set or derived data product available to the data consumer.

Post Condition

The data consumer has access to a merged data set or derived data product with appropriate metadata to accurately reflect licensing and attribution.

Use Case for Programmatic Access to Multiple Data Sets

This use case describes the situation where an application or system will access multiple data sets programmatically for the purpose of creating a merged data set or a derived data product. The decision as to which data sets will be

Page 38


accessed will have already been made. It will be known, at the time of access, whether the data sets have licenses attached to them, and which types.

Overview

Title Programmatic Access to Multiple Data Sets Using Open Access Data Licenses or No License

Description This use case covers an application or system programmatically retrieving multiple data sets for the purpose of creating a merged data set or a derived product via GEOSS-registered data services. All licensing conditions and attributions will be found in the metadata for each data set accessed.


# Data Consumer Application or System

# Data Service

# Data Consumer


# Data Provider has appropriate metadata that contains license information, if applicable.

# The data consumer is aware of any licensing conditions attached to the data sets to be accessed, and has completed any negotiations necessary.

# The data consumer application or system is aware of the licensing conditions attached to the data sets to be accessed.

Basic Flow

Step 1: Data consumer’s application or system interoperates with the appropriate data services to retrieve all requested data.

Step 2: If not part of the data in Step 1, the data consumer’s application or system interoperates with the data services to access and retrieve the metadata associated with all data from Step 1.

Step 3: Data consumer’s application or system verifies that the licensing conditions in the metadata match the licensing conditions expected. This includes attribution information, if applicable to the license used.

Step 4: If licensing conditions are validated, including a check for a non-existent license, then the application or system continues execution as expected; otherwise, execution related to the accessed data halts and the data consumer is notified of a licensing issue to be rectified.

Step 5: Data consumer’s application or system isolates all licensing conditions for analysis.

Step 6: Data consumer’s application or system takes all license conditions and determines the collective license to be associated with the merged data or data product.

Step 7: Data consumer’s application or system takes all attributions and generates new attribution metadata to reflect the merged data or data product.

Step 8: Data consumer’s application or system generates metadata for merged data or data product that reflects the new licensing conditions and attribution.

Step 9: Data consumer’s application or system makes merged data set or derived data product available to the data consumer, or continues with processing.

Post Condition

The state of the data consumer’s application or system reflects the license check. If successful, the data

Page 39


consumer’s application or system has successfully generated a merged data set or derived data product with appropriate metadata to accurately reflect licensing and attribution.

5.4 Test ImplementationsIn AIP-6, there were no test implementations of GEOSS Data-CORE compatible licenses. This occurred due to no responses to the AIP-6 Call for Participation regarding this activity. Attempts were made to find appropriate data providers to participate in testing these licenses, but none were identified.

5.5 Results and Next Steps (conclusions and recommendations)The only result that occurred for this activity was the demonstration of populating ISO 19115 metadata with the appropriate content to represent a GEOSS Data-CORE compatible license associated with a GEOSS Data-CORE data resource.

The recommended next steps for this activity include: Identifying data providers to test the implementation and use cases. Demonstrating the population of metadata for metadata standards other than ISO 19115. To integrate the GEO DAB and GEOSS Web Portal as GCI components participating in the use and visualization of GEOSS Data-CORE compatible licenses. Extending the capabilities of license support is response to the DSWG effort to define a licensing framework larger than just GEOSS Data-CORE compatible licenses. Generating the appropriate documentation and tutorials needed to inform and educate the data providers and data users with regards to GEOSS Data-CORE compatible licenses.

Page 40


6. Use Cases

6.1 AIP Engineering Use Cases[This section summarizes the AIP Use Cases which are currently under development. An update may be required prior to the final ERs.]

The GEOSS AIP Architecture approach supports the several SBA communities with a reusable process of SBA Scenarios and Engineering Use Cases.8 Scenarios are implemented by use cases. Use cases describe reusable functionality of the GEOSS service oriented architecture implemented through Interoperability Arrangements.

A summary of GEOSS AIP Use Cases is shown in Figure 4 with details provided in the following tables. In addition to the actors shown in Figure 4 the GEOSS Actors involved in GEOSS use cases are listed in Table 2.

Figure 4 – GEOSS AIP Use Case Summary Diagram

Table 2 – GEOSS ActorsActor Description Role TypeGEOSS User Discovers, consumes, and exploits GEOSS

resourcesPrincipal

GEOSS Resource Provider

Deploys, operates, registers GEOSS resources Principal

SBA Integrator Builds network of organizations and components to achieve objectives on an SBA community

Secondary

8 For details, see “AIP Development Process,” http://earthobservations.org/documents/cfp/201202_geoss_cfp_aip5_development_process.pdf

Page 41

http://earthobservations.org/documents/cfp/201202_geoss_cfp_aip5_development_process.pdf


GCI Operator Operates GCI components and approves registrations

Administrative

Table 3 – Publish Resources Use CasesName Description Actors (may be optional)

P1. Register Resources(AIP-3 ER: 1)

Register resources in GEOSS Components and Services Registry (CSR) or Community Catalog

GEOSS Resource Provider SBA Integrator – optional GCI Operator – optional

P2. Deploy a Service(AIP-3 ER: 2)

Deploy services for use in GEOSS. GEOSS Resource Provider SBA Integrator – optional

P3. Test a Service(AIP-3 ER: 09)

Service Provider tests its deployed service using a proper Test tool discovered in the GEOSS CSR.

GEOSS Resource Provider SBA Integrator – optional

P4. Develop SBA network(AIP-3 ER: 14)

Identify resources in particular services relevant to an SBA. Promote concerted use on a larger-scale

SBA Integrator GEOSS Resource Provider

Table 4 – Discover Resources Use CasesName Description Actors (may be optional)

D1. Search for Resources (AIP-3 ER: 4)

Search for resources of interest. Variations: user initiated (e.g. GWP), process initiated, searching data sharing conditions.

GEOSS User

D2. Aggregate Metadata9

(AIP-3 ER: 3)

Harvesting and/or query metadata from community catalogs or services via GEOSS Clearinghouse

GEOSS Resource Provider SBA Integrator GCI Operator

D3. Conduct semantic search(AIP-3 ER: 13)

Utilize mediated vocabularies to extend GEOSS search queries across disparate domains or communities.

GEOSS User

D4. Semantic mapping(AIP-3 ER: 12)

Register, mediate, and map between disparate vocabularies used to describe GEOS resources.

SBA Integrator GEOSS Resource Provider GCI Operator

D5. Launch Enabler App(AIP-4)

Associated with resources discovered in GCI are enabler applications, e.g., clients. User launches help application including context from previous search.

GEOSS User

9 See also the Catalogue Use Case in “OGC Engineering Report: Water Information Services Concept Development Study,” OGC Document 11-013r6, 2011-07-012.

Page 42


Table 5 –Visualize and Access Use CasesName Description Actors (may be optional)

A1. Web Mapping(new)

Access web maps services and display a composite map to the user. Allow user to modify map layers. Variation: include use of portrayal service

GEOSS User

A2. Access files(new)

Retrieve a file from an access server using FTP. Variations include: user-initiated, process-initiated.

GEOSS User if user initiated.

A3. Access data via services (AIP-3 ER: 5&6)

Access data from using a service that allows for user selection of data returned based on content. Variation: use of Access Broker

GEOSS User if user initiated

A4. User Authentication(new)

User login with single sign-on (SSO). May used with Use Cases: A2, A3, W1. Variations: user-initiated, process-initiated.

GEOSS User

A5. Access with Acknowledgement(new)

May used with Use Cases: A2, A3, W1. Variations: user-initiated, process-initiated.

GEOSS User

A6. Exploit Data (AIP-3 ER: 7)

Exploit - visually and analytically- in Client Applications using information retrieved through access use cases.

GEOSS User

Table 6 – Process and Automate Use CasesUse Case Description Actors W1. Execute Processing Service(AIP-3 ER: 11)

Invoke a processing service, to produce new derivative data resources. Variations: user-initiated, process-initiated

GEOSS User

W2. Construct and Deploy Workflow(AIP-3 ER: 8)

Design, deploy and execute a workflow. Described in Business Execution Language (BPEL) or any other script language.

SBA Integrator GEOSS User

W3. Process with Waiver or License(new)

Use metadata containing information about the waiver or license to handle aggregation of data, derived data, re-use of data, and layered data.

GEOSS User if user initiated

Page 43


Table 7 – Maintain and Support Use CasesUse Case Title ActorsM1. Register Interoperability Arrangements (AIP-3 ER: 10)

Register Interoperability Arrangements in the GEOSS SIR

GEOSS Resource Provider SBA Integrator GCI Operator

M2. Share Best Practices(AIP-3 ER: 15)

Create a Best Practice relevant to GEOSS in the GEOSS BP Wiki

GEOSS User GEOSS Resource Provider SBA Integrator GCI Operator

M3. Monitor Services(AIP-3 ER: 10)

Services registered with GEOSS are routinely monitored for network connectivity and application response.

GCI Operator

M4. User Registration(new)

User information is provided to a centralized authentication server to support single sign-on (SSO) with GEOSS providers.

GEOSS User GCI Operator

M5. Metrics Management(new)

GEOSS data provider, or GCI, gathers access and use metrics and stores information for reporting to the GCI. Variations: reports pushed, reports available for query

GEOSS User GEOSS Resource Provider GCI Operator

Page 44


7. Implementation

7.1 Deployed ComponentsFor authentication and SSO, AIP-6 resulted in the deployment and operation, as a prototype, of the COBWEB SSO federation. In particular, the Trust Gateway was deployed by the University of Edinburgh to allow OpenID users to authenticate and enter the COBWEB SAML-2 federation.

The use metrics component has yet to be implemented and deployed, but will in AIP-7.

There are no deployed components for GEOSS Data-CORE compatible license support.

7.2 Interoperability ArrangementsThe only interoperability arrangements relevant are the credential exchange protocols for OpenID and SAML-2.

7.3 Use of the GCIThe authentication and SSO trust gateway does not currently interact with the GCI, but in AIP-7 there will need to be an effort to have the GEO DAB and the GEOSS Web Portal participate in the recommended GEOSS-wide authentication and SSO federation. This interaction will involve the passing and verifying of authentication credentials, including user identity attributes, such as “GEOSS User.”

7.4 Demonstration

7.4.1 Detailed Storyboard

7.4.2 Demo video

7.5 Future plans for deploymentFor authentication and SSO, there will be more deployed trust gateways in order to fully realize a GEOSS-wide SSO federation. These will be deployed and tested by data providers or their organizations. The hope is that this federation can be operational in 2015.

Regarding use metrics, the plan is to deploy a Use Metrics Component by the end of 2014 that can be made operational. It is not implemented yet, but it is not a very sophisticated component to develop. It needs to be implemented and deployed by the GEO Secretariat if an AIP participant does not come forward to do it for AIP-7.

Page 45


8. References

GEOSS Architecture Implementation Pilot (AIP) http://www.ogcnetwork.net/AIpilot

GEOSS Data Sharing Action Plan http://www.earthobservations.org/documents/geo_vii/07_GEOSS%20Data%20Sharing%20Action%20Plan%20Rev2.pdf

GEOSS Data Sharing Principles http://www.earthobservations.org/geoss_dsp.shtml

GEOSS Data Sharing Principles Implementation Guidelines http://www.earthobservations.org/documents/geo_vi/07_Implementation%20Guidelines%20for%20the%20GEOSS%20Data%20Sharing%20Principles%20Rev2.pdf

GEO Work Plan 2012-2015 http://www.earthobservations.org/documents/work%20plan/GEO%202012-2015%20Work%20Plan_Rev2.pdf

“Towards Voluntary Interoperable Open Access Licenses for the Global Earth Observation System of Systems (GEOSS),” Harlan Onsrud, James Campbell, Bastiaan van Loenen, International Journal of Spatial Data Infrastructures Research, under review

Page 46

http://www.earthobservations.org/documents/work%20plan/GEO%202012-2015%20Work%20Plan_Rev2.pdf

http://www.earthobservations.org/documents/work%20plan/GEO%202012-2015%20Work%20Plan_Rev2.pdf



http://www.earthobservations.org/geoss_dsp.shtml



http://www.ogcnetwork.net/AIpilot

Documents

GEOSS Community Scenario · Web viewGenerate tutorial documentation for user registration, authentication, and SSO for placement in the Best Practices Wiki and distribution to data