-
Notifications
You must be signed in to change notification settings - Fork 112
VoT first draft #1868
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VoT first draft #1868
Conversation
paul-grassi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Love the new grammar check in GH review
| _This section is normative._ | ||
|
|
||
| VOT is comprised of components, and components contain values. | ||
| Vectors of Trust (VoT) is a standard for expressing information about an authentication transaction from an IdP to an RP. This information is split into several orthogonal component categories, much in the same way that the assurances defined in 800-63 are split into different xAL categories. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this consistent with C? Should we say transaction or assertion? Or at least fold assertion into this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The assertion is passed around in the transaction, but we do mean the transaction here. We'll need to check -C to make sure we get the wording right.
|
|
||
| This document uses three categories defined in VoT: Identity Proofing (P), Primary Credential Usage (C), and Assertion Presentation (A). These categories correspond to the Identity Assurance Level (IAL), Authenticator Assurance Level (AAL), and Federation Assurance Level (FAL), respectively. | ||
|
|
||
| This document does not use the Primary Credential Management (M) category defined in VoT. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm thinking we should at M, even if that means an update to B
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an implicit universal M throughout all of -3.
|
|
||
| This document does not use the Primary Credential Management (M) category defined in VoT. | ||
|
|
||
| This document does not define any additional component categories. Any additional categories SHALL NOT be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
THis is fine, but what happens if iGov defines more? We need some sort of superceding statement, maybe in the doc section that just states 'iGov is approved'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If iGov defines more then it'll need its own anchor document. That document is allowed to explicitly inherit values from here. We're saying that if you want to do the 800-63-D flavor of VoT then it comes with these categories and values and none others.
| IAL maps into the VOT component | ||
| |IAL|Component Value| | ||
| |:----:|:--:| | ||
| |IAL1 (with no attributes)|P0| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm surprised u are ok with this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had argued initially for an IAL0 equivalent like this, but we folded it into IAL1. This fits with the IETF version of P0 as well, which is a nice parallel.
| |IAL1|Self-asserted attributes|P1| | ||
| |IAL2|Unsupervised Remote and In-Person|P2| | ||
| |IAL3|Supervised Remote or In-person|P3| | ||
| In addition, the type of proofing used MAY be indicated using an alphabetic identifier. Multiple alphabetic identifiers MAY be used simultaneously. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We will likely need examples, but not necessary now since this is a 'get on the same sheet of music' draft.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely, examples will need to be everywhere. I didn't want to write examples until we had some idea what we're giving examples of.
| |IAL3|Supervised Remote or In-person|P3| | ||
| In addition, the type of proofing used MAY be indicated using an alphabetic identifier. Multiple alphabetic identifiers MAY be used simultaneously. | ||
|
|
||
| |Proofing method|Component Value| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we really need to expose 'sub-sub methods since we deemed them equivalent, but let's consider a vector for:
remote - 1 form of id (there is one case where this is allowed)
in person: supervised remote
And we should have an assertion for 'we've chosen based on risk to be IALx but not implement the requirements'. And maybe a URI to the document that states the compensating controls???
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with taking or chopping any of the non-numeric values for each category. They're there as examples and we should be generous with them now and edit them out later.
|
|
||
| In addition, the type of authenticator used SHALL be indicated using an alphabetic identifier. Multiple aphabetic identifiers MAY be used simultaneously. | ||
|
|
||
| |Authenticator|Component Value| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
our know our fed friends are going to balk at this. 'we want acronyms!'.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
aphabetic -> alphabetic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of these are acronyms, too bad. :-P
| ### FAL to VOT Component Values | ||
|
|
||
| |IAL|Vector| | ||
| FAL maps into the VoT component A using a numeric identifier. Only one numeric identifier SHALL be used. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Protocol? As-SAML?Ak-kerb?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a bad idea, though that's got more to do with the mechanics of presentation than the contents of the assertion. We could try it but my gut says I don't think we'd see much use or value in it. Still, add in now and edit out later.
No description provided.