1. OMG Mailing List
  2. IEF Reference Architecture 1.0 FTF

Open Issues

  • Issues not resolved
  • Name: ief-ftf
  • Issues Count: 15

Issues Descriptions

ISSG Request Message does not match document figure 39?

  • Key: IEFRA-15
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    ISSG Request Message does not match document figure 39?

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:26 GMT
  • Updated: Wed, 12 Jul 2017 19:32 GMT

typo for TrustmarkData

  • Key: IEFRA-14
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    typo for TrustmarkData (ISSG Response Message) in mars/2017-05-03 ; XSD for ISMD and supporting data types

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:24 GMT
  • Updated: Wed, 12 Jul 2017 19:31 GMT

Clarify permissions required for file access within folders

  • Key: IEFRA-13
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    For folder access it isn’t clear, but It think from the flow diagram that not only do you need folder permission to list the folder contents, but also permission to access each item in the folder to display it in the list? Is this correct? It wasn’t entirely clear.
    (looks like this is different from Unix execute directory permissions)

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:11 GMT
  • Updated: Wed, 12 Jul 2017 19:31 GMT

Add clarifying note that alternative implementations for email are possible

  • Key: IEFRA-12
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    For file retrieval I note that for extremely large files it could be inefficient to retrieve the entire file to parse out the SAC to get the meta data and then deny; would spec disallow a smarter file server that returns only the metadata (over the secure bus) as a first step , then only retrieve file if authorized? I believe answer is spec would not disallow this.

    This would be an implementation optimization and the flows are only examples

    Adding a note to this effect might be helpful, along with this optimization example for email.

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:09 GMT
  • Updated: Wed, 12 Jul 2017 19:30 GMT

Verify that XSD, figures and text match for Attribute names etc

  • Key: IEFRA-11
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    Verify that attribute names match (e.g. spelling etc) in text, figures and XSD

    I noticed some inconsistencies (filed in a separate issue) which suggest an automated verification would be valuable.

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 17:00 GMT
  • Updated: Wed, 12 Jul 2017 19:30 GMT

Resolve inconsistency of text and number of response values listed for AuthorizationResponseType entry

  • Key: IEFRA-10
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    Annex B
    AuthorizationResponseType entry

    text says "As per the XACML standard, this field can take one of three values"

    but

    in table more than 3 are defined, not clear how this can be. Assume that this spec is thus extending what can be returned beyond what the XACML standard defines. Maybe text should be clarified with “but the IEF defines additional values as shown here”

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:58 GMT
  • Updated: Wed, 12 Jul 2017 19:29 GMT

Add (new) security considerations section

  • Key: IEFRA-9
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    In general, I think it could be useful for such a document to have a security considerations section that outlines in broad terms some of the major security assumptions (and associated risks) that are applicable. For example, elsewhere in the body of the IEF RA it notes that a secure messaging bus is necessary, and that this separates the traffic from other traffic and provides protection. Another example might be how external services can be trusted, and how far vulnerabilities could propagate through the system (e.g. issues with key strength, algorithms etc, CA issues etc) and how such issues might be detected. Another item might be prevention of bypassing proxies (e.g managed in most cases via prior encryption). These high level notions are not implementation specific but are assumptions for the overall architecture, and also relate to implementation.

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:54 GMT
  • Updated: Wed, 12 Jul 2017 19:29 GMT

Fix spelling errors.

  • Key: IEFRA-8
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    Please run spell checker on entire document.

    I noticed the following spelling errors:

    I assume ‘defence’ is the French spelling, I am familiar with ‘defense’. Thus 'defence-in-depth’ could be updated.

    1.7.3 specifiy

    3.1 #11 change two typos, "IEF Reference Arcitecture FRP” to "IEF Reference Architecture RFP”

    suggest adding informative reference for SAMSON:
    http://cradpdf.drdc-rddc.gc.ca/PDFS/unc251/p804697_A1b.pdf

    6.7 replace in with is in UAF defintion last sentence

    Annex A, Annex B (multiple instances)
    machione

    Annex B
    "into e PPS” InfromationElementMetadata

    Annex B - PPS Policies
    confimin
    is issues

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:48 GMT
  • Updated: Wed, 12 Jul 2017 19:19 GMT

Entry #12 has * but no associated text

  • Key: IEFRA-7
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    Entry #12 has * but no associated text - if this is a footnote, where did the associated text go?

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:46 GMT
  • Updated: Wed, 12 Jul 2017 19:18 GMT

Typos in attribute names, mismatches with XSD

  • Key: IEFRA-6
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    Figure 39: Request-Identity-Attrubute should be Request-Identity-Attribute (ISSG Request Message)
    also doesn’t match XML - XSD has ""Requested-IdentityAttribute”
    (I have not compared all XML with all figures, but noticed this one)

    Figure 40: Typo, TrustmatkData (ISSG Response Message)
    element name in XML is “Trustmark”, not “Trustmarks” in diagram
    typo for TrustmarkData is in XSD file as well

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:44 GMT
  • Updated: Wed, 12 Jul 2017 19:17 GMT

Fix typos in Figures 5 and 10

  • Key: IEFRA-5
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    figure 5 send-email
    typo “receie" in alt -all recipients authorized

    Figure 10
    Instance Deployment not Instant Deployment (in caption)

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:42 GMT
  • Updated: Wed, 12 Jul 2017 19:17 GMT

Figure text is blurred and not clear

  • Key: IEFRA-4
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    Fix figure to be clear at various resolutions, text is not readable. Figure 2 and 9.

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:39 GMT
  • Updated: Wed, 12 Jul 2017 19:16 GMT

Meaning of parenthetical "suite or virtual machine" not clear

  • Key: IEFRA-3
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    The Meaning of parenthetical "suite or virtual machine" not clear - add text to clarify for reader.

    (first sentence of section)

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:37 GMT
  • Updated: Wed, 12 Jul 2017 19:16 GMT

Fix Broken URL links in glossary


Correct OMG document URLs

  • Key: IEFRA-1
  • Status: open  
  • Source: Fujitsu ( Frederick Hirsch)
  • Summary:

    OMG document identifiers need to follow standard OMG format

    Annex A
    "mars20170503" (use mars/2017-05-03)

    Annex B
    "mars 20170504" (use mars/2017-05-04)

  • Reported: IEF-RA 1.0b1 — Wed, 12 Jul 2017 16:30 GMT
  • Updated: Wed, 12 Jul 2017 19:14 GMT