gsa/ficam-arch

This is the old location for the FICAM Architecture. New location below.

This work is supported by the GSA Office of Government-wide IT Policy in coordination with the ICAM Subcommittee of the Federal CIO Council.

FICAM Architecture

This repository is for the collaborative development of the Federal Identity, Credential, and Access Management segment architecture. The repository contains Version 3.0, and a draft of Version 3.1, replacing the older (circa 2009-2011) FICAM Roadmap and Implementation Guidance v2.0, Sections 1-4.

The FICAM Architecture focuses on the federal enterprise identity and access processes, practices, policies and information security disciplines.

A federal enterprise identity is the unique representation of an employee, contractor, or enterprise user, which could be a mission or business partner, or even a device or technology managed by a Federal agency to achieve its mission and business goals. See OMB Memo 19-17.

General Practices

This content is Vendor neutral. Marketing materials for Commercial Products should not be submitted.

Plain Language

Contributors should consider the audience when submitting content. Plain language benefits a broad audience. Review your proposed content for use of acronyms and specialized jargon before submitting.

How to Contribute

For information on how to contribute to the site, visit the Contribute page here. The source repository exists here.

• pages contains markdown pages for the Introduction, Goals & Objectives, Standards & Policies, and Component application examples.
• usecases contains pages for each of the example use cases. The example use cases do not represent all possible options. Additional use cases are welcome
• services contains pages for each of the ICAM service areas (Identity, Credential, Access, Governance, & Federation)
• All diagrams and images should be placed in img

Direct changes and line edits to the content may be submitted by clicking 'Edit this page'. You do not need to install any software to submit content. You can use GitHub's in-browser editor to edit files and submit a request for your changes to be merged.

Public domain

This project is in the worldwide public domain.

This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication.

All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.

Special Thanks

This site is deployed on Federalist.

Special thanks to the government wide teams for contributions, and adopting open and transparent models to benefit citizens, government, and technology.

ficam-arch's Issues

ICAM Services Framework Descriptions - Main Category Descriptions

Description of Issue:

Recommend that the main categories, Identity Management, Credential Management, Access Management, Federation, and Governance also have brief descriptions, as the subcategories do.

Details of Issue:

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

https://arch.idmanagement.gov/services/

ICAM Services Framework Descriptions - Logging vs. Auditing

Description of Issue:

Auditing & Reporting covers the oversight of ICAM programs, but is silent on logging entity actions. Where should that go?

Details of Issue:

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

https://arch.idmanagement.gov/services/

ICAM Services Framework Descriptions - Administrative Corrections / Comments

Description of Issue:

1. There are inconsistent spellings of life cycle and lifecycle.
2. Policy Administration uses “rule sets”; I’ve seen this written as one word, too.
3. Registration uses the singular “person” and then uses the plural “them”.

Details of Issue:

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

https://arch.idmanagement.gov/services/

Update style sheets

• Update the style sheets to use web design / uswds styles
• Remove any external references

ICAM Services Framework Descriptions - Difference Between Entitlement Management and Provisioning

Description of Issue:

There is too much overlap between Entitlement Management and Provisioning. The former includes “maintaining … permissions for a person …” and the latter includes “Linking and unlinking access permissions for a person …”? Is that not maintaining? Is there a clearer boundary between these two or should they be combined?

Details of Issue:

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

https://arch.idmanagement.gov/services/

NIST SP 800-63-3 document update

Description of Issue:

Details of Issue:

In reference to the NIST SP 800-63-3 document, is there a time-frame when the official FICAM document will be updated?

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

ICAM Services Framework Descriptions - Federation Section Ordering

Description of Issue:

Under Federation, should Credential Bridging be first, since generally authentication precedes creating assertions or exchanging attributes?

Details of Issue:

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

https://arch.idmanagement.gov/services/

Privileged Access (comment)

Description of Issue:

• CDM has one additional category of applications under access management: privileged access managers
• Consider how to align

Governance Definitions (revamp)

Alternative comments to #143

• Update the governance services and applications view
• Focus on (and update) identity governance versus broader governance activities for approaches in the service definitions view
• Align with CDM definitions
• Remove "software" from the applications sub-components definitions and view

Policy of redistribution

Description of Issue:

Training

Details of Issue:

Not a computer geek

References (Docs, Links, Files):

?

If a New Page or Content is Needed,

Expected Outcomes: ####

Link to the Content Page for Contributors:

Identity Management Definitions (comments)

Received June 2019 - a federal agency comment for updating identity management service definitions

Comments on :

Item	Current Text	Recommended Change	Change	Rationale
Identity Management	Identity Management is the set of practices that allow an organization to establish, maintain, and terminate identities.	Identity Management is the set of practices that allow an organization to establish, maintain, and terminate digital identities.	Add "digital" before "identities".	Ensure no misunderstanding by casual readers of something ICAM practitioners take for granted.
Identity Proofing	Verifying information to establish the identity of a person or entity.	Verifying information to establish the identity of an entity.	Change "a person or entity" to "an entity".	Entity covers both persons and non-persons.
Creation	Establishing a digital identity composed of attributes that define a person or entity.	Establishing a digital identity composed of attributes that define an entity.	Change "a person or entity" to "an entity".	Entity covers both persons and non-persons
Identity Maintenance	Maintaining accurate and current attributes within an identity record over its life cycle.	Maintaining accurate and current attributes within an identity record over its lifecycle.	1) Change title to "Identity Maintenance" 2) Change "life cycle" to "lifecycle"	1) The title should be descriptive enough that it can stand alone 2) Lifecycle is usually written as one word in this context
Identity Resolution	Finding and connecting disparate identity records for the same person or entity.	Finding and connecting disparate identity records for the entity.	Delete "person or".	Entity covers both persons and non-persons.
Deactivation	Deactivating or removing an identity record.	none

Add this repository to the GSA code inventory

(I work in GSA IT, Office of the CTO. I am submitting this as part of our work to ensure GSA complies with the new Federal Source Code Policy.)

GSA needs to create an inventory of all agency source code, whether open source or closed source. The inventory we create will appear on Code.gov. The inventory will contain basic information about each source code repository, but will not include the source code itself. Please read the implementation guide and use it to submit this repository to the inventory by December 5.

Basically, please do one of the following, the details of which are described in the implementation guide:

• Add a metadata file (.codeinventory.yml or .codeinventory.json) to this repository (optionally, use this tool to generate a metadata file)
• Submit your metadata via a form (only do this if you cannot add a metadata file to this repository)

Let me know if you would like me to open a PR with an example .codeinventory.yml file.

Please let me know if you have any questions.

Thanks!

---

References:

• GSA Open Source Implementation Guide
• GSA Open Source Policy
• Federal Source Code Policy

Add me to the repository

Can I be added to the repository so I can clone it down to my laptop? Or is web only the policy?

Thanks,
Steve Howard

Goals & Objectives: Goal 1.2 (spelling mistake?)

Goal 1.2 in the Diagram states:

Enable Agencies to establish and manage prove, trusted identities for all system users

Should be:

Enable Agencies to establish and manage proven, trusted identities for all system users

Document History Section and Versioning

I recommend:

1. A version numbering scheme be implemented for the document that is incremented each time the document is officially updated. The title of the document should reflect the version.
2. A document history be included, possibly in background section or having its own section that includes the version number, date of the version change and a summary of the changes.
3. Should 1 and/or 2 be applied, there should be a link or other ready means by which one could readily go to a previous version.

Rationale: Absent the above, the document is problematic to cite to -- not only for research purposes, but also for pointing to in standards/policy documents and contracting instruments / agreements.

For example, agreements may point to the document as reflecting a common understanding on a particular date. If the document is constantly changing without a versioning or document history record, agreeing parties might find it difficult to determine agreed to terms that were present on the date of the agreement -- absent github training. Such training is likely too much of an ask for the target audience.

Update styles to USWDS 2.x

Description of Issue:

Update styles and template to use USWDS 2.x

Details of Issue:

Old, old version of USWDS (0.9?) currently in use

References (Docs, Links, Files):

https://designsystem.digital.gov/

If a New Page or Content is Needed, Expected Outcomes:

This is a medium effort.
The navigation (sub and side) and all assets in _includes need to reference newer styles. Clean assets, etc.

ICAM Services Framework Descriptions - Issuance Wording

Description of Issue:

Issuance begins with “Transferring a credential to a person …”. The verb seems odd since normally credentials are created and assigned (i.e. issued) to persons.

Details of Issue:

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

https://arch.idmanagement.gov/services/

IDESG Functional Areas - where should any alignment be?

Open for discussion

Where should the alignment be with the IDESG Functional Areas?

• http://www.idesg.org/The-ID-Ecosystem/Identity-Ecosystem-Framework/IDEF-Core-Documents

Governance would be an easy one.

One of the challenges I see is that we are Services framework focused, while the IDESG core documents are Functional model focused.

At a minimum, we should align terms?

FEA Diagram - Simpler descriptions?

I'm proposing simplifying the Descriptions on the FEA alignment diagram (http://gsa.github.io/ficam-arch/index.html).

Diagram -> Simplified Description

• Conceptual Diagram -> An entry point to understanding
• Goals & Objectives -> The strategy driving implementation
• Services Framework -> The set of services that provides functionality
• Business Process Diagram -> Functional view of processes applied to user populations
• Use Cases -> Common sequence of steps to deliver User functionality
• Applications Interface Diagrams -> Common enterprise applications supporting business functionality

I'm reviewing content for Plain Language principles, and proposing alternate language: http://www.plainlanguage.gov/howto/quickreference/checklist.cfm

Derived PIV Lifecycle Support

Description of Issue:

Is there documentation, plan, schedule for Derived PIV life-cycle federal support?

Details of Issue:

If an agency wants to enable DPIV for their mobile devices and apps, where can it turn for DPIV life-cycle support like PIV life-cycle support. Any planning work? Any scheduled support?

References (Docs, Links, Files):

https://arch.idmanagement.gov/usecases/24_createderivedpiv/

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

Governance Definitions (comments)

Received June 2019 - a federal agency comment for updating governance service definitions

Comments:

Item	Current Text	Recommended Change	Change	Rationale
Enterprise Governance	Developing and implementing the policies, rules, and procedures to manage and improve an ICAM program.	none
Auditing & Reporting	Monitoring, reviewing, and reporting on an ICAM program's conformance with rules, policies, and requirements.	none
Redress	Fixing problems and vulnerabilities that occur during standard operation of an ICAM program.	Mitigating risks, threats, and vulnerabilities that occur during operation of an ICAM program.	1) Change "Fixing" to "Mitigating" 2) Change "problems" to "risks, threats"	1) Mitigation is broader than "fixing" and recognizes cannot always eliminate vulnerabilities 2) Risks and threats are broader than "problems".
Recovery	Preparing the procedures and assets that would be needed to recover from a security or privacy breach and ensure continuity or service.	Preparing the procedures and assets needed to recover from failures or breaches associated with ICAM to ensure the security and continuity of service.	1) Change "a security or privacy breach" to "failures or breaches" 2) Add "associated with ICAM" 3) Add "the security and"	1) Recovery responsibilities must address more than just breaches 2) Limit scope to ICAM 3) Scope must include more than continuity of service

Use case 4: LOA4 + biometrics

Description of Issue:

Step 6 is the capture of biometric modalities. This step is performed after the steps for the validation of the identity is performed. This assumes that the validation of the identity can we done with a government issued ID and additional information provided, such as an account number.
I'm a first time contributor, so I will try to fill this out as best as I can.

Details of Issue:

The last step in LOA4 is the capture of biometric modalities to increase the level of non-repudiation. There is a practice in many countries where a government agency has biometric information of its citizens and is capable of providing biometric comprisson services to validate the identity of a person, and sometimes a national ID is issued. We should be aiming at this goal. Currently, that agency doesn't exist in the US, but we can use other agency to perform the same task. Additionally, there are identitiy sources that can be used to perform this same task. So, instead of verifying a government issued ID or an account number only, we can include the biometric verification of the identity.
Additionally, the governement agency itself can perform a biometric identification (1:N search) to reduce the possibility of having duplicated identity records. This task, deduplication of digital identity records, should be mandatory for LOA4. This is closely related to use case 5, as a match result to avoid deduplication should include the resolution of a possible biometric match.

References (Docs, Links, Files):

https://arch.idmanagement.gov/usecases/14_proofidentityloa4/

If a New Page or Content is Needed, Expected Outcomes:

New content recomendation.
Use case 4 should have biometric data captured in step 3.
Use case 4 should have biometric data verification in step 4.
Use case 4 should have a new step 5 for biometric identification, internal and external, to avoid DIR duplication. This would replace the current step 5 for confirmation, and move it to step 6.
Use case 4 should have a new step 6 for confirmation. This would replace the current step 6 for biometric capture. The current step 6 for biometric capture should be eliminated.

Expeted outcomes.
An increased level of assurance on the identities managed by the system. Additional features to verify identities.
I would recomend a similar analysis for use case 8.

Link to the Content Page for Contributors:

Access Management Definitions (comments)

Received June 2019 - a federal agency comment for updating identity management service definitions

Comments on:

Item	Current Text	Recommended Change	Change	Rationale
Policy Administration	Creating and maintaining the rule sets that govern access to protected resources.	Creating, maintaining and distributing digital policies that govern access to information resources.	1) Add "and distributing" 2) Change "rule sets" to "digital policies" 3) Change 'protected' to 'information'	1) Distribution of policies should also be included here 2) Digital policies is a more inclusive term than rule sets 3) Better word for this level of detail
Entitlement Management	Establishing and maintaining the authoritative access permissions for a person or entity.	Establishing and maintaining the authoritative access permissions for an entity.	Change "a person or entity" to "an entity".	1) Entity covers both persons and non-persons Question [for FICAM]: What's the difference between Entitlement Management and Provisioning? What's the difference between an entitlement and an attribute and an access permission?
Provisioning	Linking and unlinking access permissions for a person or entity to a protected resource.	Opportune associating and dis-associating authorization attributes to entities to provide for access to and use of information resources.	Rewrite	Question [for FICAM]: What's the difference between Entitlement Management and Provisioning? 1) "Opportune" is unnecessary and confusing as to its intent
Authentication	Verifying that a claimed identity is genuine based on valid credentials.	Verifying that a claimed identity's validity based on trusted credentials is genuine with a measurable level of assurance.	1) Change "identity is genuine" to "identity's validity" 2) Change "valid" to "trusted" 3) Add "is genuine with a measurable level of assurance"	1) Subtlety about whether authentication checks the validity of the credential or the claimed identity 2) Credentials must be trusted not only at the point of authentication, but in asserting authentication across boundaries. 3) Credentials must provide a measurable level of assurance so needed levels of trust can be leveraged commensurate with the environment and the activity for which authentication is needed.
Authorization	Granting or denying access requests to protected resources based on a policy determination.	Granting or denying entity access requests to information resources based on determination by a digital policy.	1) Add "entity" 2) Change "protected" to "information" 3) Change "policy determination" to "determination by a digital policy"	1) Attribute the access to an entity 2) Better word 3) Clarity

Goals & Objectives: Goal 2.1

Current states in diagram:

Automate information discover and access across the Federal Government in all security domains

Should be?

Automate information discovery and access across the Federal Government in all security domains

Applications Diagram - Enterprise versus Customer

http://gsa.github.io/ficam-arch/applications/
ficam-arch/pages/ficam_applications.md

I think we should add another view to the Applications Diagrams.

• The Enterprise IAM versus the Customer IAM.

Former is built to scale horizontally, with features meant for workflows, auditing, lots of integration points, etc.

The latter is built to scale vertically - one or two types of users, all the same, same information, same processes, higher volume of users.

From an Applications Diagram standpoint, you do want to keep them separate (separate IAM solution architectures, development approaches, and deployment).

Test Issue

Test test

Update color schemes and wording to match between conceptual and services

Description of Issue:

Conceptual overview and Services framework are using different color schemes and wording

Details of Issue:

One intent from the working group was to synthesize the I, C, AM areas and show clear alignment from one artifact to the next

Link to the Content Page for Contributors:

/imgs/
ficam-arch/pages/ficam_conceptual.md
ficam-arch/_services/overview_services.md
ficam-arch/_services/*

Rewrite Credentials with more plain language

ficam-arch/_services/12_credentials.md

update to align with consumer identity playbook, remove unnecessary words, add change anything in parentheses

Credential Management Definitions (comments)

Received June 2019 - a federal agency comment for updating identity management service definitions

Comments:

Item	Current Text	Recommended Change	Change	Rationale
Sponsorship	Formally establishing that a person or entity requires a credential.	Formally establishing that an entity  requires a credential.	Change "a person or entity" to "an entity".	Entity covers both persons and non-persons.
--	--	--	--	--
Registration	Collecting the information needed from a person or entity to issue them [sic] a credential.	Collecting the information needed from an entity to issue that entity a credential.	1) Change "person or entity" to "an entity" 2) Change "them" to "that entity"	1) Entity covers both persons and non-persons. 2) "Them" is plural yet the object referred to is singular.
Issuance	Transferring a credential to a person or entity.	Providing and/or binding a credential to an entity.	1) Change "Transferring" to "Providing and/or binding". 2) Change "a person or entity" to "an entity".	1) Credentials are not always 'transferred' and recognition of the credential binding to an entity or entity persons may be needed for relationship assurance. 2) Entity covers both persons and non-persons.
Credential Maintenance	Maintaining a credential over its life cycle.	Maintaining a credential over its lifecycle.	1) Change title to "Credential Maintenance" 2) Change "life cycle" to "lifecycle"	1) The title should be descriptive enough that it can stand alone 2) Lifecycle is usually written as one word in this context
Revocation	Withdrawing a credential from a person or entity.	Withdrawing a credential from an entity.	Change "a person or entity" to "an entity"	1) Entity covers both persons and non-persons.

Update Federation description to include "intra-app" federation

Include information from FICAM v2.0 Section 12 (part B)

• Clarify description for business stakeholders
• Inter-organization reuse versus...
• More clearly identify inter-application reuse (form of Federation) from an enterprise perspective
• Tie back to centralized identity application service areas

Expanding use case for "Create and Issue Derived PIV"

We talked about this briefly before. We should incorporate Secure Token Services (STS) and other derived credential capabilities.

In looking at the Create and Issue Derived PIV (http://gsa.github.io/ficam-arch/usecases/24_createderivedpiv/) use case, there is a scenario where an STS from a trusted network could obviate the need for a mobile device. An example would be the STS leveraging Windows authentication on a trusted environment to establish a derived PIV. Conceptually, this would be an Identity Provider acting on behalf of the individual and an STS is an operational example.

https://arch.idmanagement.gov/usecases/ conflates credential federation and authentication federation

Description of Issue:

The use case overview at https://arch.idmanagement.gov/usecases/ conflates credential federation and authentication federation. Item 20 and Item 16 should never be in the same path. That is, if “Access” is applying credential federation, then Item 20 is superfluous because an external (federated) user is presenting a credential directly to Access. On the other hand, if authentication federation is applied, Item 16 is superfluous because an accepted authentication assertion is conveyed from Item 20 to Items 17/18.

Details of Issue:

Submitted for Jim Thomson from email, July 6 2018

References (Docs, Links, Files):

https://arch.idmanagement.gov/usecases/
Use cases 16 and 20

If a New Page or Content is Needed, Expected Outcomes:

Updates to content requested

Link to the Content Page for Contributors:

Add Search Box To FICAM Arch

Description of Issue:

There is no search feature in the FICAM Arch Guides.

Details of Issue:

Add a search box to FICAM Arch Guides and post the data to search.usa.gov. The feature will be similar to the one provided at idmanagement.gov.

References (Docs, Links, Files):

Should be added to the navbar.html and it will be included in all pages. Possibly replace the "View this site's code" button on the top navigation.

If a New Page or Content is Needed, Expected Outcomes:

New search box in FICAM Arch Guides website.

Link to the Content Page for Contributors:

Identity Governance and Access Certifications

Description of Issue:

The FICAM Services Architecture does not include clear guidance on Access Certification/Attestation. As part of the CDM Phase 2 SailPoint deployment participating agencies now have access to the tools necessary to streamline this process and increase efficiencies and accuracy.

Details of Issue:

The SailPoint IdentityIQ Unified Governance Platform and Compliance Manager is being installed as the solution for the Master User Record. Compliance Manager enables agencies to;

Identity Warehouse and Resource Connectors

• Creates a single system of record for users, applications and entitlements with an extensive connector library for synchronizing data across on-prem and cloud apps

Policy Model

• Delivers access policy enforcement to enhance organizational security, lower risk, and meet regulatory compliance requirements

Role Model

• Simplifies the administration, request, review and fulfillment of user access by aligning access to job function

Risk Model

• Identifies organizational risk caused by inappropriate access and enables prioritization of controls to mitigate the risk

Data-driven Workflow Engine

• Combines data-driven workflow approach across compliance and provisioning activities with a visual designer to simplify business process modeling

Business-friendly Access Certifications

• Reduces the cost and burden of compliance
• Simplifies campaign setup, admin and tracking
• Streamlines access review process by focusing on areas of high-risk
• Automates removal of excess access rights

Automated Policy Management

• Rapidly defines and deploys policies across applications (e.g., SoD)
• Automatically scans, detects and remediates violations
• Leverages risk to prioritize policy enforcement

Audit Reporting and Analytics

• Demonstrates compliance with pre-defined audit reports
• Creates transparency to IAM data across enterprise and cloud apps

References (Docs, Links, Files):

https://www.sailpoint.com/

DHS CDM Master User Record (MUR) Functional Description

If a New Page or Content is Needed, Expected Outcomes:

SailPoint will support the development of the necessary content

Link to the Content Page for Contributors:

Update Standards and Policies links

Description of Issue:

The links in the Standards and Policies will need updates.

Details of Issue:

Some of the document links are outdated, some point to the wrong repositories (OMB memoranda), and some links are broken.

References (Docs, Links, Files):

https://arch.idmanagement.gov/standards/
The updates to the links will be provided.

If a New Page or Content is Needed, Expected Outcomes:

Verify that the links that are updated with new ones.

Link to the Content Page for Contributors:

https://github.com/GSA/ficam-arch/blob/staging/pages/ficam_standards_policies.md

Consistency of Template.md pages

Description of Issue:

The content contained in the Template.md pages (and their locations in the directory structures) is not consistent across the FICAM-Arch, FPKI-Guides, and PIV-Guides repos.

Details of Issue:

1. The Template.md pages provide style and general instructions for those who need to write guides or information for the FICAM-Arch, FPKI-Guides, and PIV-Guides.
2. The content contained in the Template.md pages is not consistent across the 3 repos.
3. The Template.md pages are not located at the same directory structure level for all 3 repos.

References (Docs, Links, Files):

https://github.com/GSA/ficam-arch/blob/staging/template.md
https://github.com/GSA/fpki-guides/blob/staging/template.md
https://github.com/GSA/fpki-guides/blob/staging/pages/template.md
https://github.com/GSA/piv-guides/blob/staging/pages/template.md

If a New Page or Content is Needed, Expected Outcomes:

1. Make the content consistent for all Template.md pages: sample outline for guides, the same style and general instructions, and Markdown syntax (style sheet).
2. Place all Template.md pages in a consistent location in the directory structures for all 3 repos.

Link to the Content Page for Contributors:

None.

ICAM Services Framework Descriptions - Title Uniqueness

Description of Issue:

Subcategory names should be unique and identifiable if they stand apart from their category title. Thus Creation should be Identity Creation, Maintenance should be Identity Maintenance (and Credential Maintenance). The others, such as [Credential] Issuance can at least be inferred.

Details of Issue:

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

https://arch.idmanagement.gov/services/

Perform automated and manual 508 checks

Description of Issue:

Use AMP or ANDI to perform automated and manual 508 tests.

Details of Issue:

Top Issues
1 | Avoid use of placeholder values to label or explain input
2 | Ensure headers and cells are properly associated
3 | Ensure the language of a document is set
4 | Ensure ARIA regions, landmarks and HTML sections are identifiable
5 | Ensure links or controls that open new windows or frames do not open without a warning

Vote: Removing the word "holistic" from all diagrams and text?

Let's have a vote? 👍

Update jquery

Use case #20 [Accept Credentials in a Federation] should be revisited to use terms consistent with NIST 800-63-3.

Description of Issue:

Use case #20 [Accept Credentials in a Federation] should be revisited to use terms consistent with NIST 800-63-3. Note that “validate” and “verify” appear to be used interchangeably. Also, “verification assertion” is not a NIST 800-63C term. This flow is not what’s portrayed in the user case overview, although I appreciate that you can’t show all of the detail.

Details of Issue:

Submitted for Jim Thomson, via email July 6, 2018

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

Federation Definitions (comments)

Received June 2019 - a federal agency comment for updating federation service definitions

Item	Current Text	Recommended Change	Change	Rationale
Attribute Exchange	Discovering and sharing identity attributes between different systems to promote interoperability and simplify the process for establishing an identity.	Discovering and cquiring identity attributes between different systems to promote interoperability.	1) Change "sharing" to "acquiring". 2) Delete "and simplify the process for establishing an identity."	1) "acquiring" is a better word, since attribute exchange is rarely bidirectional for a given identity. 2) Deleted "Establishing an identity" since it is a design decision (either because the software won't work w/o a directory record, or for caching, or for audit, but they aren't the point of exchanging attributes.
Credential Translation	Transforming a token or credential into an alternative format, potentially containing claims about the client, for acceptance at a relying party.	Transforming a token or credential into an alternative format, potentially containing claims about the entity, for acceptance at a resource.	1) Change client" to "entity 2) Change Relying Party" to "resource"	1) Should not introduce new term "client" when it's not needed at this high level 2) This was only occurrence of Relying Party. Also, should use limited set of terms.
Credential Bridging	Establishing a cross-certified, affiliated relationship to trust credentials at a level of assurance asserted by those credentials.	none
Policy Alignment	Establishing a mutual relationship between parties by deliberately establishing common standards and principles.	Establishing relationships and a common understanding between parties through use of authoritative policies, standards, principles, and authorities.	1) Delete "mutual" and make "relationships" plural 2) Add "and a common understanding" 3) Change "by deliberately establishing" to "through use of" 4) Add "authoritative policies" and "authorities".	1) Word choice 2) Add the purpose of the relationship 3) Better words; "deliberately" is peculiar choice 4) To be inclusive, a broader set of policies and authorities in addition to standards and principles

broken links under services

Description of Issue:

/services
broken links (404 errors)
reported by colleagues at State (thank you!)

Details of Issue:

links under main page for /ficam-arch/services/ return 404

Defin LOA

I'm not sure if this qualifies as an issue, rather than a comment, but the Business Process Diagram (which is great!) should define LOA.

ICAM Services Framework Descriptions - Risk

Description of Issue:

Where should risk accounted for? NIST 800-63-3 expands and encourages using measures that inform risk-based authentication and authorization decisions, but the closest connection is Credential Bridging, which covers only AALs and only for federated issuers.

Details of Issue:

Maybe risk is covered under Policy Administration but I think it should be more explicit. A related issue is Trust, which must be in Federation, as it applies to the confidence in partners and their ICAM processes.

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

https://arch.idmanagement.gov/services/

Business process - move the words from the diagram header to web text?

http://gsa.github.io/ficam-arch/businessprocess/
ficam-arch/pages/ficam_business_process.md

The image itself contains the header words ("The diagram below...")

I think it might be more useful to remove the header words, put those in the body of the page, along with key (federal entities, business partners, customers) - and let the diagram just be the visual element.

This way agencies or consumers can use the visual element and add their own words if they want to reuse.

Thoughts

Use Case #15 [Grant Access to a Protected Resource] should be updated for Assurance Levels consistent with NIST 800-63-3

Description of Issue:

Use Case #15 [Grant Access to a Protected Resource] should be updated for Assurance Levels consistent with NIST 800-63-3

Details of Issue:

Submitted for Jim Thomson, from email July 6, 2018

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

The World Serpent

Quantum-theory between the Many Worlds and the Copenhagen Interpretation

Details of Issue:

Jordmundgandr. Natures defense against time paradoxes, how it affects science within a frequency delayed projection, a linear time dimension...Our reality...!!!

It reflects us, our subconsciousness and our reality, a regular formatted reality.

The Universal Laws of Observation

1. "Only in Darkness (False, non-communication)
   do you understand the Light (True, communication)."

2. "It is each and everyone`s own responsibility to evolve."

3. "You cannot imagine, the imaginary unknown of the Almighty Unknown."
   (Binary-coded quantum-philosophy)

The Existence,
(m)-personification, in (m)-personation.
“If and only if existence. In nature, nature is existence. Existence is nature, nature in existence. Is, if (in)-personation is existence… (m) -personification. “The Many” is existence, the Gamma-universe extension.”

          A realist stance in quantum-philosophy.                                Super-galactic science.
                              Epistemic vs Ontic phenomenology.
           Auto-epistemic expansion, known propositional logic and quantum mechanics.

References (Docs, Links, Files):

If a New Page or Content is Needed, Expected Outcomes:

Link to the Content Page for Contributors:

Add custom 404

Description of Issue:

We are proposing changing a URI (/applications to /components)

Details of Issue:

If we make this change and there are embedded links in other docs, we should include an updated/custom 404 as well

References (Docs, Links, Files):

It doesn't seem like we added a custom 404 yet to this repo.
Simple example: https://github.com/GSA/fpki-guides/blob/staging/404.md
Federalist guide for custom 404's: https://federalist.18f.gov/documentation/customization/

Mobile Image and Text Rendering

The text rendering when viewing the page on a mobile device resizes to whatever size of the image. See attached. Difficult when reading on a mobile device and something to keep in mind when adding larger images.