An Update on Digital Library Access Methods

David Millman

Columbia University

June 2002

Millman—2002-June—2

Survey: Some Access Mgmt Methods

1. One Collection, multiple organizations

2. Fragmented collections

3. More private

4. Federated collections

5. Removing central administration

Millman—2002-June—3

Single Collection

• simple• low security• low privacy• poor scaling

Org OrgOrg

admin

Collection

Millman—2002-June—4

1. One Collection, multiple organizations

2. Fragmented collections

3. More private

4. Federated collections

5. Removing central administration

Millman—2002-June—5

Fragmented Collections

• central admin• optional distributed

admin• flexible service

packages / licensing• scaling?

Org OrgOrg

adm

C C C C C

{ {

adm{

Millman—2002-June—6

1. One Collection, multiple organizations

2. Fragmented collections

3. More private

4. Federated collections

5. Removing central administration

Millman—2002-June—7

Organizational Authentication

• locally authenticated• credentials do not leave

org admin• higher security & privacy• e.g., WebISO (I2),

pubcookie (UWash), CAS (Yale), WIND (Columbia)

Org

C

admAuthNAuthZ

?

Millman—2002-June—8

1. One Collection, multiple organizations

2. Fragmented collections

3. More private

4. Federated collections

5. Removing central administration

Millman—2002-June—9

Federated Collections(e.g., NSDL?)

• independent collections• central admin• + mandatory distributed

admin• moderate scaling• higher security• moderate privacy (central

portal interface & profile services)

Org OrgOrg

C C C C

adm adm adm

portal profiles

adm

Millman—2002-June—10

1. One Collection, multiple organizations

2. Fragmented collections

3. More private

4. Federated collections

5. Removing central administration

Millman—2002-June—11

Federated w/o Central Architecture(e.g., NSDL)

• no central technology(or only a bit)

• central policy• good scaling• good privacy &

security

Org OrgOrg

C C C C

adm adm adm

portal profiles

(policy)

Millman—2002-June—12

Federated w/o Central Architecture(e.g., NSDL)

• no central technology(or only a bit)

• central policy• good scaling• good privacy &

security

Org OrgOrg

C C C C

adm adm adm

portal profiles

(policy)

Shibboleth

Millman—2002-June—13

NSDL Architecture (abbreviated)

• ~ 80 collections (most unrestricted)

• ~ 20 services

• core technical infrastructure– metadata repository– search– access management– portal

Millman—2002-June—14

Shibboleth Dependencies

• SAML (oasis-open.org)

• architecture (middleware.internet2.edu)

• policy specification (perhaps per community of use)

Millman—2002-June—15

Shibboleth Requirements

• organization authentication infrastructure

• community authorization infrastructure

• target service software add-on

• “where-are-you-from?” service

• community policy framework

Millman—2002-June—16

NSDL Access Mgmt Policy Goals

• specify– communities of use (for subscribers)– conditions of use (for collections/publishers)

• subscribers: requirements for participation, e.g., character of local authentication (enforcement roles and methods), conformance to definitions of community membership

• publishers: practices re identity aggregation, discovery, disclosure

• clarify technology vs legal/administrative policy

Millman—2002-June—17

Access Architecture Next Steps

• relationship to interfaces– Learning Management Systems– portals generally

• relationship to collections– as “repositories” (citation mgmt, versioning,

archival concerns, license repurpose)

end