TWiki
>
IVOA Web
>
IvoaResReg
>
VOResource-1_1-Errata
>
VOResource-1_1-Erratum-1
(revision 1) (raw view)
Edit
Attach
---+ VOResource Erratum 1: Re-enable multiple security methods per interface Author: Markus Demleitner Date last changed: 2019-02-05 Date accepted: Not yet accepted ---++ Rationale In VOResource 1.0, an interface element could have multiple securityMethods. When VOResource 1.1 was written, it appreared that common deployments of authenticated services would in general use different access URLs for different authentication methods (which is what securityMethod describes). Since no records actually used securityMethod (let alone multiple securityMethods) at that time, in the interest of keeping the relational mapping as close to the actual model as possible it was decided to change the relation to a 1:1 one. Later implementation experience now suggests that most authentication techniques deployers actually want to use work on a common endpoint URL, and that actual implementations make use of this fact in order to keep the handy notion of *the* access URL of a service, a notion popular with many VO users. It seems unreasonable to keep VOResource documents from clearly expressing the fact that a certain capability is exposed on one URL. Since multiple authentication technologies can still be employed on each interface, we have to return to the 1:n relationship between interface and securityMethod. ---++ Erratum Content In the schema (VOResource-v1.1), the following two lines: <pre> <xs:element name="securityMethod" type="vr:SecurityMethod" minOccurs="0" maxOccurs="1"> </pre> are changed to <pre> <xs:element name="securityMethod" type="vr:SecurityMethod" minOccurs="0" maxOccurs="unbounded"> </pre> In the VOResource 1.1 REC document, the following changes are made: * PDF p. 36 in "vr:Interface Type Schema Definition": replace macOccurs="1" with maxOccurs="unbounded" in the xs:element for securityMethod. * PDF p. 37, in "Occurrence" of the "Element securityMethod": Add "multiple occurrences allowed" after "optional". * PDF p. 40, first bullet point ("interface now only allows zero or one securityMethod elements..."): The entire bullet point is removed. ---++ Impact Assessment The change loosens a restriction; hence, no registry documents will become invalid through this change. On the consumer side, the change retracted here was intended to simplify implementation of RegTAP 1.1. RegTAP 1.1 is still under review as this erratum is being written in hence can easily be changed to cope with this erratum.
Edit
|
Attach
|
Watch
|
P
rint version
|
H
istory
:
r6
|
r4
<
r3
<
r2
<
r1
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r1 - 2019-02-05
-
MarkusDemleitner
IVOA
Log in
or
Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Applications
Data Access Layer
Data Model
Distributed Services & Protocols
Registry
Semantics
Interest Groups
Data Curation
Education
Knowledge Discovery
High Energy
Operations
Radio Astronomy
Solar System
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback