Difference: VOResource-1_1-Erratum-1 (1 vs. 6)

Revision 62019-05-29 - TheresaDower

 
META TOPICPARENT name="VOResource-1_1-Errata"

VOResource 1.1 Erratum 1: Re-enable multiple security methods per interface

Author: Markus Demleitner

Date last changed: 2019-02-05

Changed:
<
<
Date accepted: Not yet accepted
>
>
Date accepted: 2019-05-12
Deleted:
<
<
 

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 (“security”) methods. 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 between interface and securityMethod 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 for a minor benefit of RegTAP ingestors. Hence, in this erratum we return to the 1:n relationship between interface and securityMethod that existed in VOResource 1.0.

A related issue is how services that allow both authenticaticated and unauthenticated access communicate that fact. Conventionally (and currently for >99.9% for resources), the lack of any securityMethod declaration has indicated an open resource. In original VOResource 1.1, the intent has been to simply add an interface without any security method. With the single-interface approach now preferred, this is undesirable. Therefore, open access will, by this erratum, be indicated by a security method without a standardID.

Erratum Content

In the schema (VOResource-v1.1), the lines:

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="1">

(lines 1127f) are changed to

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="unbounded">

Also in the schema, the second documentation element of the securityMethod child of the interface type definition (starting line 1134),

    <xs:documentation>
       Services not requiring authentication must provide
       at least one interface definition without a 
       securityMethod defined.
    </xs:documentation>

is changed to

    <xs:documentation>
       A missing securityMethod child indicates an interface usable without authentication.  
       In the presence of at least one securityMethod element, services indicate the possibility of
       unauthenticated access using an empty securityMethod element (i.e., one without standardID).
    </xs:documentation>

In the VOResource 1.1 REC document, the following changes are made:

  • PDF p. 36 in "vr:Interface Type Schema Definition": replace maxOccurs="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. 37, the "Comment" of the "Element securityMethod": Replace current content with "A missing securityMethod child indicates an interface usable without authentication. In the presence of at least one securityMethod element, services indicate the possibility of unauthenticated access using an empty securityMethod element (i.e., one without standardID)."
  • 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.

Revision 52019-04-05 - MarkTaylor

 
META TOPICPARENT name="VOResource-1_1-Errata"

VOResource 1.1 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 (“security”) methods. 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 between interface and securityMethod 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 for a minor benefit of RegTAP ingestors. Hence, in this erratum we return to the 1:n relationship between interface and securityMethod that existed in VOResource 1.0.

A related issue is how services that allow both authenticaticated and unauthenticated access communicate that fact. Conventionally (and currently for >99.9% for resources), the lack of any securityMethod declaration has indicated an open resource. In original VOResource 1.1, the intent has been to simply add an interface without any security method. With the single-interface approach now preferred, this is undesirable. Therefore, open access will, by this erratum, be indicated by a security method without a standardID.

Erratum Content

In the schema (VOResource-v1.1), the lines:

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="1">

(lines 1127f) are changed to

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="unbounded">

Also in the schema, the second documentation element of the securityMethod child of the interface type definition (starting line 1134),

    <xs:documentation>
       Services not requiring authentication must provide
       at least one interface definition without a 
       securityMethod defined.
    </xs:documentation>

is changed to

    <xs:documentation>
       A missing securityMethod child indicates an interface usable without authentication.  

Changed:
<
<
In the presence of at least one securityMethod element, services indicate the possiblity of
>
>
In the presence of at least one securityMethod element, services indicate the possibility of
  unauthenticated access using an empty securityMethod element (i.e., one without standardID). </xs:documentation>

In the VOResource 1.1 REC document, the following changes are made:

Changed:
<
<
  • PDF p. 36 in "vr:Interface Type Schema Definition": replace macOccurs="1" with maxOccurs="unbounded" in the xs:element for securityMethod.
>
>
  • PDF p. 36 in "vr:Interface Type Schema Definition": replace maxOccurs="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. 37, the "Comment" of the "Element securityMethod": Replace current content with "A missing securityMethod child indicates an interface usable without authentication. In the presence of at least one securityMethod element, services indicate the possibility of unauthenticated access using an empty securityMethod element (i.e., one without standardID)."
  • 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.

Revision 42019-03-29 - BrianMajor

 
META TOPICPARENT name="VOResource-1_1-Errata"

VOResource 1.1 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 (“security”) methods. 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 between interface and securityMethod 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.

Changed:
<
<
It seems unreasonable to keep VOResource documents from clearly
>
>
It seems unreasonable to keep VOResource documents from clearly expressing the fact that a certain capability is exposed on one URL for a minor benefit of RegTAP ingestors. Hence, in this erratum we return to the 1:n relationship between interface and securityMethod that existed in VOResource 1.0.
Deleted:
<
<
expressing the fact that a certain capability is exposed on one URL for a minor benefit of RegTAP ingestors. Hence, in this erratum we return to the 1:n relationship between interface and securityMethod that existed in VOResource 1.0.
  A related issue is how services that allow both authenticaticated and unauthenticated access communicate that fact. Conventionally (and currently for >99.9% for resources), the lack of any securityMethod declaration has indicated an open resource. In original VOResource 1.1, the intent has been to simply add an interface without any security method. With the single-interface approach now preferred, this is undesirable. Therefore, open access will, by this erratum, be indicated by a security method without a standardID.

Erratum Content

In the schema (VOResource-v1.1), the lines:

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="1">

(lines 1127f) are changed to

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="unbounded">

Also in the schema, the second documentation element of the securityMethod child of the interface type definition (starting line 1134),

    <xs:documentation>
       Services not requiring authentication must provide
       at least one interface definition without a 
       securityMethod defined.
    </xs:documentation>

is changed to

    <xs:documentation>
       A missing securityMethod child indicates an interface usable without authentication.  
       In the presence of at least one securityMethod element, services indicate the possiblity of
       unauthenticated access using an empty securityMethod element (i.e., one without standardID).
    </xs:documentation>

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".
Changed:
<
<
  • PDF p. 37, the "Comment" of the "Element securityMethod": Replace current content with "A missing securityMethod child indicates an interface usable without authentication. In the presence of at least one securityMethod element, services indicate the possiblity of unauthenticated access using an empty securityMethod element (i.e., one without standardID)."
>
>
  • PDF p. 37, the "Comment" of the "Element securityMethod": Replace current content with "A missing securityMethod child indicates an interface usable without authentication. In the presence of at least one securityMethod element, services indicate the possibility of unauthenticated access using an empty securityMethod element (i.e., one without standardID)."
 
  • 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.

Revision 32019-02-25 - MarkusDemleitner

 
META TOPICPARENT name="VOResource-1_1-Errata"

VOResource 1.1 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 (“security”) methods. 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 between interface and securityMethod 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.

Changed:
<
<
It seems unreasonable to keep VOResource documents from clearly expressing the fact that a certain capability is exposed on one URL for a minor benefit of RegTAP ingestors. Hence, in this erratum we return to the 1:n relationship between interface and securityMethod that existed in VOResource 1.0.
>
>
It seems unreasonable to keep VOResource documents from clearly
Added:
>
>
expressing the fact that a certain capability is exposed on one URL for a minor benefit of RegTAP ingestors. Hence, in this erratum we return to the 1:n relationship between interface and securityMethod that existed in VOResource 1.0.
  A related issue is how services that allow both authenticaticated and unauthenticated access communicate that fact. Conventionally (and currently for >99.9% for resources), the lack of any securityMethod declaration has indicated an open resource. In original VOResource 1.1, the intent has been to simply add an interface without any security method. With the single-interface approach now preferred, this is undesirable. Therefore, open access will, by this erratum, be indicated by a security method without a standardID.

Erratum Content

In the schema (VOResource-v1.1), the lines:

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="1">

(lines 1127f) are changed to

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="unbounded">

Also in the schema, the second documentation element of the securityMethod child of the interface type definition (starting line 1134),

    <xs:documentation>
       Services not requiring authentication must provide
       at least one interface definition without a 
       securityMethod defined.
    </xs:documentation>

is changed to

    <xs:documentation>

Changed:
<
<
A missing securityMethod child indicates an interface usable with authentication.
>
>
A missing securityMethod child indicates an interface usable without authentication.
  In the presence of at least one securityMethod element, services indicate the possiblity of unauthenticated access using an empty securityMethod element (i.e., one without standardID). </xs:documentation>

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. 37, the "Comment" of the "Element securityMethod": Replace current content with "A missing securityMethod child indicates an interface usable without authentication. In the presence of at least one securityMethod element, services indicate the possiblity of unauthenticated access using an empty securityMethod element (i.e., one without standardID)."
  • 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.

Changed:
<
<
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.
>
>
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.

Revision 22019-02-06 - MarkusDemleitner

 
META TOPICPARENT name="VOResource-1_1-Errata"
Changed:
<
<

VOResource Erratum 1: Re-enable multiple security methods per interface

>
>

VOResource 1.1 Erratum 1: Re-enable multiple security methods per interface

  Author: Markus Demleitner

Date last changed: 2019-02-05

Date accepted: Not yet accepted

Rationale

Changed:
<
<
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.
>
>
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 (“security”) methods. 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 between interface and securityMethod to a 1:1 one.
 
Changed:
<
<
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.
>
>
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.
 
Changed:
<
<
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.
>
>
It seems unreasonable to keep VOResource documents from clearly expressing the fact that a certain capability is exposed on one URL for a minor benefit of RegTAP ingestors. Hence, in this erratum we return to the 1:n relationship between interface and securityMethod that existed in VOResource 1.0.
 
Added:
>
>
A related issue is how services that allow both authenticaticated and unauthenticated access communicate that fact. Conventionally (and currently for >99.9% for resources), the lack of any securityMethod declaration has indicated an open resource. In original VOResource 1.1, the intent has been to simply add an interface without any security method. With the single-interface approach now preferred, this is undesirable. Therefore, open access will, by this erratum, be indicated by a security method without a standardID.
 

Erratum Content

Changed:
<
<
In the schema (VOResource-v1.1), the following two lines:
>
>
In the schema (VOResource-v1.1), the lines:
 
         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="1">
Changed:
<
<
are changed to
>
>
(lines 1127f) are changed to
 
         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="unbounded">
Added:
>
>
Also in the schema, the second documentation element of the securityMethod child of the interface type definition (starting line 1134),

    <xs:documentation>
       Services not requiring authentication must provide
       at least one interface definition without a 
       securityMethod defined.
    </xs:documentation>

is changed to

    <xs:documentation>
       A missing securityMethod child indicates an interface usable with authentication.  
       In the presence of at least one securityMethod element, services indicate the possiblity of
       unauthenticated access using an empty securityMethod element (i.e., one without standardID).
    </xs:documentation>
 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".
Added:
>
>
  • PDF p. 37, the "Comment" of the "Element securityMethod": Replace current content with "A missing securityMethod child indicates an interface usable without authentication. In the presence of at least one securityMethod element, services indicate the possiblity of unauthenticated access using an empty securityMethod element (i.e., one without standardID)."
 
  • 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.

Revision 12019-02-05 - MarkusDemleitner

 
META TOPICPARENT name="VOResource-1_1-Errata"

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:

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="1">

are changed to

         <xs:element name="securityMethod" type="vr:SecurityMethod"
                     minOccurs="0" maxOccurs="unbounded">

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.

 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback