XMLWordPrintable

    Details

    • Type: Bug
    • Status: New
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: Authentication Step-Up Protocol and Metadata Version 1.0
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      Conformance

    • Proposal:
      Hide

      Re-cast conformance clauses to enable readers to distinguish conforming authentication and authorization systems from those that don't conform.

      Show
      Re-cast conformance clauses to enable readers to distinguish conforming authentication and authorization systems from those that don't conform.

      Description

      8 Conformance reads:

      *****
      [1] MUST include components and services that enable requesting additional authentication or identification claims from the Subject for subsequent re-evaluation of authorization policy, as described in Section 3.1 and Section 3.2 of this document.

      [2] MUST contain a discrete Trust Elevation Services component and services as defined in the Trust Elevation Architecture described in Section 4.2.1 of this document.
      *****

      Just make sure we are on common ground, is it fair to say that:

      *****
      MUST include components and services that enable requesting additional authentication or identification claims from the Subject for subsequent re-evaluation of authorization policy, as described in Section 3.1 and Section 3.2 of this document.
      *****

      References the purely abstract model of trust elevation?

      That is there are no requirements for use of particular trust methods, paths of elevation, protocols for communication, format of messages in either direction, etc. ?

      I ask because if that is true, then no system which elevates trust requirements could be said to not conform to at least the first requirements. That is I can't distinguish between a system that conforms and one that does not. Fairly important if interoperability is at issue.

      You may have intended constraints on syntax, protocols, etc. but that didn't come across in the present conformance clause.

      The second conformance clause:

      *****
      MUST contain a discrete Trust Elevation Services component and services as defined in the Trust Elevation Architecture described in Section 4.2.1 of this document.
      *****

      Suffers from a similar vagueness. Was there an intention to harken back to earlier work of the TC? If so, those references are missing.

      I would summarize the issue with the question: How do I distinguish a conforming authentication and authorization system, where it receives input and requests additional verification and a non-conforming system where it receives input and requests additional verification?

      I know the TC and its editors know that answer but I can't determine what it may be from the draft as written.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              patrick Patrick Durusau
            • Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: