Subject: Re: [VoT] vot Digest, Vol 5, Issue 6

From: Peter Alterman <[email-masked]>
Date: Tue, 13 Jan 2015 13:00:25 -0500

​Happy new year to you all.  I've been reading the mail but unable to break
away long enough to comment until now. As I read it, the issue on the table
is how to express trustworthiness.

If Abbie was here he'd point you all to the one-to-one correlation between
trust and threat/threat vector mitigation.​ I recommend to you the Third
Deliverable of the OASIS Trust Elevation TC  - link provided upon
demonstration of curiosity ;-)

 An RP trusts an external assertion of identity (or even extended
attributes) to the extent that the assertion is created and/or can be
verified to a predetermined degree of threat/risk mitigation. This degree
is baked into policy or contract or some other pre-existing agreement
(think banking regulations, etc.) and is locally determined based upon
local considerations, e.g., no global standard is appropriate.  So far as I
can see, vectors of trust are the same thing as the threats and threat
vectors that are enumerated in ISO 29115 and other places, not least of
which are controls in NIST 800-53-4 and in ISO 27001/2. I really don't see
the vectors as anything different from these and considering
trustworthiness as the inverse of threat in this context is pretty much
what everybody seems to be saying.

If we just use 29115 as our baseline of threats and threat vectors, there
are roughly a dozen or so of them associated with authentication of
identity assertion. I don't think any of us believe that a
twelve-dimensional assertion is practically viable, even if we could agree
on a common metric for degree of threat mitigation (fat chance that). This
has also already been addressed by the community: think of the factor
model, one to four factors (the fourth is context, which may be expressed
as "Where or when you are," according to our colleagues). What this does is
boil down the trust/threat algorithm to no more than four dimensions and
shifts the discussion to the aforementioned conundrum, e.g., how to
evaluate and rate the degree of threat mitigation. Various communities have
developed policies and practices to address this question, the most recent
of which, I think, is EU Regulation 910/2014 (eIDAS).

IMO, the greatest opportunity open to us is to find a way to normalize all
the various community policies and practices so that RPs can assess whether
assertions issued under one community's metrics align with their adopted
risk mitigation requirements. I think that has to be addressed in the
context of how effective a particular mitigation action is on a recognized
threat vector.   I would be most interested in your thoughts on that
problem.

regards,

Peter

------------------------------------------------------------
Peter Alterman, Ph.D.
Chief Operating Officer
SAFE-BioPharma Association
cell: 301-943-7452

On Tue, Jan 13, 2015 at 8:19 AM, <[email-masked]> wrote:

> Send vot mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/vot
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vot digest..."
>
> Today's Topics:
>
>    1. Re: capturing the threads of the discussion (Robin Wilton)
>    2. VoT wiki (Steve Olshansky)
>
>
> ---------- Forwarded message ----------
> From: Robin Wilton <[email-masked]>
> To: Colin Wallis <[email-masked]>
> Cc: Jim Fenton <[email-masked]>, "[email-masked]" <[email-masked]>
> Date: Tue, 13 Jan 2015 09:31:59 +0000
> Subject: Re: [VoT] capturing the threads of the discussion
>  Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the
> place to start...
>
>  R
>
> Robin Wilton
>
> Technical Outreach Director - Identity and Privacy
>
> On 12 Jan 2015, at 23:43, "Colin Wallis" <[email-masked]> wrote:
>
>    Well as Steve O pointed out in this attached email in November, the
> wiki set up for this work might be a place to start..
>
> There may be some jiggery pokery to get the folks on this list who want to
> contribute (who were not attendees at Utrecht) access rights, but it would
> seem to me to be the obvious starter option for a repository.
>
> Cheers
>
> Colin
>
> PS: BTW this is a good discussion and indeed an opportunistic time to
> bring it together since so much of what Justin, Jim, Scott, Ken, Steve W,
> Mark et al have commented recently is complementary (well at least not
> completely contradictory or orthogonal) so let’s grab it!
>
>
>
> *From:* vot [mailto:[email-masked]] *On Behalf Of *Robin Wilton
> *Sent:* Tuesday, 13 January 2015 11:22 a.m.
> *To:* Jim Fenton
> *Cc:* [email-masked]
> *Subject:* Re: [VoT] capturing the threads of the discussion
>
>
>
> Thanks Jim,
>
>
>
> I won't give a substantive response here; just to note that I think it's
> worth considering a repository so that we can capture 'static' versions of
> any straw-man docs, to complement what we it into the mail thread...
>
>
>
> Sorry to be brief at this stage - just tying up some loose ends before an
> absence from the office.
>
>
>
> R
>
> Robin Wilton
>
>
>
> Technical Outreach Director - Identity and Privacy
>
>
> On 12 Jan 2015, at 21:45, "Jim Fenton" <[email-masked]> wrote:
>
>  Maybe I should be breaking these apart as Robin suggests, but for now
> I'll keep this in one reply:
>
> On 1/12/15 6:06 AM, Robin Wilton wrote:
>
> This thread raises several important topics… just as a practical matter,
> it might be worth trying to spin some of them off separately, so that we
> address them all, and minimise the risk of talking at cross-purposes.
>
> It feels like it would be worth trying to put together some *very short*
> straw-man docs/pages/paragraphs to try and get a consensus version on
> specific points, so that we avoid re-hashing the same arguments/discussions
> over time, or at least have something we can refer to - and amend if
> necessary. I think this is aiming at the same end-point as Steve’s request
> for a statement of requirements, but will ensure we’re expressing our
> requirements in a consistent set of terms.
>
>
>
>   By the looks of it, these would make for a good starting point (I think
> the answers to most of these are implicit in various people’s contributions
> to the thread… but that doesn’t mean everyone agrees ;^)  ):
>
>
>
>   1 - what do we mean by authentication and authorisation? Are there
> other decisions (e.g. access control, entitlement) which need to be called
> out explicitly? This reflects the purpose of Justin’s questions.
> Classically, the reason for authenticating a user is to answer a yes/no
> question (is this the person to whom this credential was originally
> issued); if yes, what do I want to do about it (at which point the further
> entitlements are usually determined by retrieving a user profile, ACL or
> whatever)?
>
>
> Access control and entitlement as distinct from authorisation? Is there a
> distinction, or are people just using different terminology?
>
> I think of authentication as providing more than a yes/no answer: it
> provides an identifier. If the relying party has enough information
> (perhaps on the basis of previous interactions) to authorize something with
> just that, fine. Otherwise some attributes are needed to make an
> authorisation decision.
>
>
>  However, as we know, these days access control and entitlement decisions
> also need to be made on the basis of input other than classic credentials,
> and that’s one of the two cores of this discussion, I believe.
>
>
> Example of an "input other than classic credentials"?
>
>
>
>
>   2 - what’s the classic lifecycle of a credential - i.e. a artefact
> intended to provide evidence in support of an assertion of identity. (e.g.
> registration/verification/enrolment, credential issue, credential
> presentation/authentication, credential amendment/revocation/destruction…)?
>
>
> Credential is another of those tricky words. Sometimes it means the same
> as an authentication token. Sometimes it has some attributes bound to it,
> which means it has both an authentication and attribute provision flavor to
> it. I find it simpler to talk about tokens, where one doesn't have to deal
> with revocation when some attribute (employment, for example) changes.
>
>
>
>   3 - How does (2) relate to other assertions (e.g. attribute assertions)
> we would like to make reliably?
>
>
>
>   With that starter set, I think we can confirm the subset of
> requirements that 800-63-1 still meets, and define the delta that requires
> new design.
>
>
>
> 4 - What’s the right way to update current thinking on LOAs, to account
> for the change Jim describes in his proposal - i.e., the case where "credentials
> (used in authentication) and attribute information (established through
> identity proofing) could be provided by different parties.”
>
>
>
> 5 - From Jim’s proposal: “Attribute reliability refers to the quality of
> the identity proofing process, as well as the strength of the binding of
> the identifying attributes to the authentication.” Do we need/want to
> expand on this a little? This seems to cater well for the case where, say,
> vehicle entitlements are being established so that they can be encapsulated
> in a driving licence. It’s not so clear how this addresses, say, third
> party assertions that do not arise from an identity proofing process - “I
> have no idea *who* this user is, but I can reliably assert the following
> about them: ... ”.
>
>
> You're right; that will need to be defined. But it should be possible to
> define analogous requirements to describe the strength of the binding to
> the token. When you show up to enroll at school, it should be possible to
> use your token to allow your school to make LOR 3 asserts that you're there
> student. But maybe remote students only get LOR 2?
>
> -Jim
>
>   All-
> There unfortunately is a long-standing bug in Confluence. You must be
> logged in before that link, or any link to a restricted page, will work.
>
> The wiki space for workshop attendees only, which you all have full edit
> access to and which is not publicly viewable, is athttps://
> tid.isoc.org/confluence/display/interfedgen/
>
> The *PUBLIC* wiki space, containing the agenda, presentations, and
> contributions/references, is at
> https://tid.isoc.org/confluence/display/interfed/
>
> As we make progress on work items and are ready to move them to the public
> wiki, I will be happy to do that. Our goal is of course to make as much of
> our work as possible available to the public, but this restricted wiki
> space gives us a place to work on things before revealing them to the world.
>
> As always, if anyone has questions or problems related to the wiki, or
> anything else, please do let me know.
>        Steve
>
> --
> Steve Olshansky
> Trust & Identity Program Lead
> Internet Society
> www.internetsociety.org
>
>
>   <signature.asc>
>
>  _______________________________________________
> Ideco-fab mailing list
> [email-masked]
> https://elists.isoc.org/mailman/listinfo/ideco-fab
>
>
>
> ---------- Forwarded message ----------
> From: Steve Olshansky <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc:
> Date: Tue, 13 Jan 2015 13:19:22 +0000
> Subject: [VoT] VoT wiki
> All-
> This is a great discussion, and the stars seem to be aligning now for the
> development of some documents or any other related artifacts.
>
> I setup a dedicated wiki space for use by this group. It is open to the
> world for viewing, but we can easily make restricted areas for the purpose
> of working on documents before publishing. Anyone would would like edit
> access is welcome to contact me directly (off-list).
> https://tid.isoc.org/confluence/display/vot/VoT+Home
>         Steve
>
> --
> Steve Olshansky
> Trust & Identity Program Lead
> Internet Society
> www.internetsociety.org
>
> On Jan 13, 2015, at 2:31 AM, Robin Wilton <[email-masked]> wrote:
>
> > Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the
> place to start...
> >
> > R
> >
> > Robin Wilton
> >
> > Technical Outreach Director - Identity and Privacy
> >
> > On 12 Jan 2015, at 23:43, "Colin Wallis" <[email-masked]>
> wrote:
> >
> >> Well as Steve O pointed out in this attached email in November, the
> wiki set up for this work might be a place to start..
> >> There may be some jiggery pokery to get the folks on this list who want
> to contribute (who were not attendees at Utrecht) access rights, but it
> would seem to me to be the obvious starter option for a repository.
> >> Cheers
> >> Colin
> >> PS: BTW this is a good discussion and indeed an opportunistic time to
> bring it together since so much of what Justin, Jim, Scott, Ken, Steve W,
> Mark et al have commented recently is complementary (well at least not
> completely contradictory or orthogonal) so let’s grab it!
> >>
> >> From: vot [mailto:[email-masked]] On Behalf Of Robin Wilton
> >> Sent: Tuesday, 13 January 2015 11:22 a.m.
> >> To: Jim Fenton
> >> Cc: [email-masked]
> >> Subject: Re: [VoT] capturing the threads of the discussion
> >>
> >> Thanks Jim,
> >>
> >> I won't give a substantive response here; just to note that I think
> it's worth considering a repository so that we can capture 'static'
> versions of any straw-man docs, to complement what we it into the mail
> thread...
> >>
> >> Sorry to be brief at this stage - just tying up some loose ends before
> an absence from the office.
> >>
> >> R
> >>
> >> Robin Wilton
> >>
> >> Technical Outreach Director - Identity and Privacy
> >>
> >> On 12 Jan 2015, at 21:45, "Jim Fenton" <[email-masked]> wrote:
> >>
> >> Maybe I should be breaking these apart as Robin suggests, but for now
> I'll keep this in one reply:
> >>
> >> On 1/12/15 6:06 AM, Robin Wilton wrote:
> >> This thread raises several important topics… just as a practical
> matter, it might be worth trying to spin some of them off separately, so
> that we address them all, and minimise the risk of talking at
> cross-purposes.
> >> It feels like it would be worth trying to put together some *very
> short* straw-man docs/pages/paragraphs to try and get a consensus version
> on specific points, so that we avoid re-hashing the same
> arguments/discussions over time, or at least have something we can refer to
> - and amend if necessary. I think this is aiming at the same end-point as
> Steve’s request for a statement of requirements, but will ensure we’re
> expressing our requirements in a consistent set of terms.
> >>
> >>
> >> By the looks of it, these would make for a good starting point (I think
> the answers to most of these are implicit in various people’s contributions
> to the thread… but that doesn’t mean everyone agrees ;^)  ):
> >>
> >>
> >> 1 - what do we mean by authentication and authorisation? Are there
> other decisions (e.g. access control, entitlement) which need to be called
> out explicitly? This reflects the purpose of Justin’s questions.
> Classically, the reason for authenticating a user is to answer a yes/no
> question (is this the person to whom this credential was originally
> issued); if yes, what do I want to do about it (at which point the further
> entitlements are usually determined by retrieving a user profile, ACL or
> whatever)?
> >>
> >> Access control and entitlement as distinct from authorisation? Is there
> a distinction, or are people just using different terminology?
> >>
> >> I think of authentication as providing more than a yes/no answer: it
> provides an identifier. If the relying party has enough information
> (perhaps on the basis of previous interactions) to authorize something with
> just that, fine. Otherwise some attributes are needed to make an
> authorisation decision.
> >>
> >>
> >> However, as we know, these days access control and entitlement
> decisions also need to be made on the basis of input other than classic
> credentials, and that’s one of the two cores of this discussion, I believe.
> >>
> >> Example of an "input other than classic credentials"?
> >>
> >>
> >>
> >>
> >> 2 - what’s the classic lifecycle of a credential - i.e. a artefact
> intended to provide evidence in support of an assertion of identity. (e.g.
> registration/verification/enrolment, credential issue, credential
> presentation/authentication, credential amendment/revocation/destruction…)?
> >>
> >>
> >> Credential is another of those tricky words. Sometimes it means the
> same as an authentication token. Sometimes it has some attributes bound to
> it, which means it has both an authentication and attribute provision
> flavor to it. I find it simpler to talk about tokens, where one doesn't
> have to deal with revocation when some attribute (employment, for example)
> changes.
> >>
> >>
> >>
> >> 3 - How does (2) relate to other assertions (e.g. attribute assertions)
> we would like to make reliably?
> >>
> >>
> >> With that starter set, I think we can confirm the subset of
> requirements that 800-63-1 still meets, and define the delta that requires
> new design.
> >>
> >> 4 - What’s the right way to update current thinking on LOAs, to account
> for the change Jim describes in his proposal - i.e., the case where
> "credentials (used in authentication) and attribute information
> (established through identity proofing) could be provided by different
> parties.”
> >>
> >> 5 - From Jim’s proposal: “Attribute reliability refers to the quality
> of the identity proofing process, as well as the strength of the binding of
> the identifying attributes to the authentication.” Do we need/want to
> expand on this a little? This seems to cater well for the case where, say,
> vehicle entitlements are being established so that they can be encapsulated
> in a driving licence. It’s not so clear how this addresses, say, third
> party assertions that do not arise from an identity proofing process - “I
> have no idea *who* this user is, but I can reliably assert the following
> about them: ... ”.
> >>
> >> You're right; that will need to be defined. But it should be possible
> to define analogous requirements to describe the strength of the binding to
> the token. When you show up to enroll at school, it should be possible to
> use your token to allow your school to make LOR 3 asserts that you're there
> student. But maybe remote students only get LOR 2?
> >>
> >> -Jim
> >>
> > vot mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/vot
>
>
> _______________________________________________
> vot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vot
>
>

---

From: "Jones, Mark B" <[email-masked]>
Date: Tue, 13 Jan 2015 18:21:17 +0000

+1

Please consider this a demonstration of curiosity in the link you offered.

Sent from my iPhone

On Jan 13, 2015, at 12:00 PM, Peter Alterman <[email-masked]<mailto:[email-masked]>> wrote:

​Happy new year to you all.  I've been reading the mail but unable to break away long enough to comment until now. As I read it, the issue on the table is how to express trustworthiness.

If Abbie was here he'd point you all to the one-to-one correlation between trust and threat/threat vector mitigation.​ I recommend to you the Third Deliverable of the OASIS Trust Elevation TC  - link provided upon demonstration of curiosity ;-)

 An RP trusts an external assertion of identity (or even extended attributes) to the extent that the assertion is created and/or can be verified to a predetermined degree of threat/risk mitigation. This degree is baked into policy or contract or some other pre-existing agreement (think banking regulations, etc.) and is locally determined based upon local considerations, e.g., no global standard is appropriate.  So far as I can see, vectors of trust are the same thing as the threats and threat vectors that are enumerated in ISO 29115 and other places, not least of which are controls in NIST 800-53-4 and in ISO 27001/2. I really don't see the vectors as anything different from these and considering trustworthiness as the inverse of threat in this context is pretty much what everybody seems to be saying.

If we just use 29115 as our baseline of threats and threat vectors, there are roughly a dozen or so of them associated with authentication of identity assertion. I don't think any of us believe that a twelve-dimensional assertion is practically viable, even if we could agree on a common metric for degree of threat mitigation (fat chance that). This has also already been addressed by the community: think of the factor model, one to four factors (the fourth is context, which may be expressed as "Where or when you are," according to our colleagues). What this does is boil down the trust/threat algorithm to no more than four dimensions and shifts the discussion to the aforementioned conundrum, e.g., how to evaluate and rate the degree of threat mitigation. Various communities have developed policies and practices to address this question, the most recent of which, I think, is EU Regulation 910/2014 (eIDAS).

IMO, the greatest opportunity open to us is to find a way to normalize all the various community policies and practices so that RPs can assess whether assertions issued under one community's metrics align with their adopted risk mitigation requirements. I think that has to be addressed in the context of how effective a particular mitigation action is on a recognized threat vector.   I would be most interested in your thoughts on that problem.

regards,

Peter

On Tue, Jan 13, 2015 at 8:19 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Send vot mailing list submissions to
        [email-masked]<mailto:[email-masked]>

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/vot<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=uc913qsLA6bZ34rLfuSc3sig7ZcIykGDReZ73Wx21L0&e=>
or, via email, send a message with subject or body 'help' to
        [email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
        [email-masked]<mailto:[email-masked]>

Today's Topics:

---------- Forwarded message ----------
From: Robin Wilton <[email-masked]<mailto:[email-masked]>>
To: Colin Wallis <[email-masked]<mailto:[email-masked]>>
Cc: Jim Fenton <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 13 Jan 2015 09:31:59 +0000
Subject: Re: [VoT] capturing the threads of the discussion
Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the place to start...

R

Robin Wilton

On 12 Jan 2015, at 23:43, "Colin Wallis" <[email-masked]<mailto:[email-masked]>> wrote:

Well as Steve O pointed out in this attached email in November, the wiki set up for this work might be a place to start..
There may be some jiggery pokery to get the folks on this list who want to contribute (who were not attendees at Utrecht) access rights, but it would seem to me to be the obvious starter option for a repository.
Cheers
Colin
PS: BTW this is a good discussion and indeed an opportunistic time to bring it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark et al have commented recently is complementary (well at least not completely contradictory or orthogonal) so let’s grab it!

From: vot [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robin Wilton
Sent: Tuesday, 13 January 2015 11:22 a.m.
To: Jim Fenton
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [VoT] capturing the threads of the discussion

Thanks Jim,

I won't give a substantive response here; just to note that I think it's worth considering a repository so that we can capture 'static' versions of any straw-man docs, to complement what we it into the mail thread...

Sorry to be brief at this stage - just tying up some loose ends before an absence from the office.

R

Robin Wilton

On 12 Jan 2015, at 21:45, "Jim Fenton" <[email-masked]<mailto:[email-masked]>> wrote:
Maybe I should be breaking these apart as Robin suggests, but for now I'll keep this in one reply:

On 1/12/15 6:06 AM, Robin Wilton wrote:
This thread raises several important topics… just as a practical matter, it might be worth trying to spin some of them off separately, so that we address them all, and minimise the risk of talking at cross-purposes.
It feels like it would be worth trying to put together some *very short* straw-man docs/pages/paragraphs to try and get a consensus version on specific points, so that we avoid re-hashing the same arguments/discussions over time, or at least have something we can refer to - and amend if necessary. I think this is aiming at the same end-point as Steve’s request for a statement of requirements, but will ensure we’re expressing our requirements in a consistent set of terms.

By the looks of it, these would make for a good starting point (I think the answers to most of these are implicit in various people’s contributions to the thread… but that doesn’t mean everyone agrees ;^)  ):

1 - what do we mean by authentication and authorisation? Are there other decisions (e.g. access control, entitlement) which need to be called out explicitly? This reflects the purpose of Justin’s questions. Classically, the reason for authenticating a user is to answer a yes/no question (is this the person to whom this credential was originally issued); if yes, what do I want to do about it (at which point the further entitlements are usually determined by retrieving a user profile, ACL or whatever)?

Access control and entitlement as distinct from authorisation? Is there a distinction, or are people just using different terminology?

I think of authentication as providing more than a yes/no answer: it provides an identifier. If the relying party has enough information (perhaps on the basis of previous interactions) to authorize something with just that, fine. Otherwise some attributes are needed to make an authorisation decision.

However, as we know, these days access control and entitlement decisions also need to be made on the basis of input other than classic credentials, and that’s one of the two cores of this discussion, I believe.

2 - what’s the classic lifecycle of a credential - i.e. a artefact intended to provide evidence in support of an assertion of identity. (e.g. registration/verification/enrolment, credential issue, credential presentation/authentication, credential amendment/revocation/destruction…)?

Credential is another of those tricky words. Sometimes it means the same as an authentication token. Sometimes it has some attributes bound to it, which means it has both an authentication and attribute provision flavor to it. I find it simpler to talk about tokens, where one doesn't have to deal with revocation when some attribute (employment, for example) changes.

3 - How does (2) relate to other assertions (e.g. attribute assertions) we would like to make reliably?

With that starter set, I think we can confirm the subset of requirements that 800-63-1 still meets, and define the delta that requires new design.

4 - What’s the right way to update current thinking on LOAs, to account for the change Jim describes in his proposal - i.e., the case where "credentials (used in authentication) and attribute information (established through identity proofing) could be provided by different parties.”

5 - From Jim’s proposal: “Attribute reliability refers to the quality of the identity proofing process, as well as the strength of the binding of the identifying attributes to the authentication.” Do we need/want to expand on this a little? This seems to cater well for the case where, say, vehicle entitlements are being established so that they can be encapsulated in a driving licence. It’s not so clear how this addresses, say, third party assertions that do not arise from an identity proofing process - “I have no idea *who* this user is, but I can reliably assert the following about them: ... ”.

You're right; that will need to be defined. But it should be possible to define analogous requirements to describe the strength of the binding to the token. When you show up to enroll at school, it should be possible to use your token to allow your school to make LOR 3 asserts that you're there student. But maybe remote students only get LOR 2?

-Jim
All-
There unfortunately is a long-standing bug in Confluence. You must be logged in before that link, or any link to a restricted page, will work.

The wiki space for workshop attendees only, which you all have full edit access to and which is not publicly viewable, is athttps://tid.isoc.org/confluence/display/interfedgen/<https://urldefense.proofpoint.com/v2/url?u=http-3A__tid.isoc.org_confluence_display_interfedgen_&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=9Oa0oZ8TzQIYwGzbvNizYYzC9CBXi1jYvNMfH2OH8RQ&e=>

The *PUBLIC* wiki space, containing the agenda, presentations, and contributions/references, is at
https://tid.isoc.org/confluence/display/interfed/<https://urldefense.proofpoint.com/v2/url?u=https-3A__tid.isoc.org_confluence_display_interfed_&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=13AdDlkdwSVnKMrzNnMjS6XGvlubZUuuLRxjXnCfyQs&e=>

As we make progress on work items and are ready to move them to the public wiki, I will be happy to do that. Our goal is of course to make as much of our work as possible available to the public, but this restricted wiki space gives us a place to work on things before revealing them to the world.

As always, if anyone has questions or problems related to the wiki, or anything else, please do let me know.
       Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.internetsociety.org&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=nhtGR7uax78r-vjT_QOwthgVx5vFK2ocRUKcPg4F65k&e=>

<signature.asc>
_______________________________________________
Ideco-fab mailing list
[email-masked]<mailto:[email-masked]>
https://elists.isoc.org/mailman/listinfo/ideco-fab<https://urldefense.proofpoint.com/v2/url?u=https-3A__elists.isoc.org_mailman_listinfo_ideco-2Dfab&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=RSHSBGQHEW5EXyhLCiGEL6C0H3rdPD12lnrj--jJekk&e=>

---------- Forwarded message ----------
From: Steve Olshansky <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:
Date: Tue, 13 Jan 2015 13:19:22 +0000
Subject: [VoT] VoT wiki
All-
This is a great discussion, and the stars seem to be aligning now for the development of some documents or any other related artifacts.

I setup a dedicated wiki space for use by this group. It is open to the world for viewing, but we can easily make restricted areas for the purpose of working on documents before publishing. Anyone would would like edit access is welcome to contact me directly (off-list).
https://tid.isoc.org/confluence/display/vot/VoT+Home<https://urldefense.proofpoint.com/v2/url?u=https-3A__tid.isoc.org_confluence_display_vot_VoT-2BHome&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=o1GEbz40RmMfS51FeqoTW7FI-VOOZxrgy9oUpPpUgdk&e=>
        Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.internetsociety.org&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=nhtGR7uax78r-vjT_QOwthgVx5vFK2ocRUKcPg4F65k&e=>

On Jan 13, 2015, at 2:31 AM, Robin Wilton <[email-masked]<mailto:[email-masked]>> wrote:

> Oops - I'd forgotten about the wiki: apologies! Yes, I think that's the place to start...
>
> R
>
> Robin Wilton
>
> On 12 Jan 2015, at 23:43, "Colin Wallis" <[email-masked]<mailto:[email-masked]>> wrote:
>
>> Well as Steve O pointed out in this attached email in November, the wiki set up for this work might be a place to start..
>> There may be some jiggery pokery to get the folks on this list who want to contribute (who were not attendees at Utrecht) access rights, but it would seem to me to be the obvious starter option for a repository.
>> Cheers
>> Colin
>> PS: BTW this is a good discussion and indeed an opportunistic time to bring it together since so much of what Justin, Jim, Scott, Ken, Steve W, Mark et al have commented recently is complementary (well at least not completely contradictory or orthogonal) so let’s grab it!
>>
>> From: vot [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robin Wilton
>> Cc: [email-masked]<mailto:[email-masked]>
>> I won't give a substantive response here; just to note that I think it's worth considering a repository so that we can capture 'static' versions of any straw-man docs, to complement what we it into the mail thread...
>>
>> Sorry to be brief at this stage - just tying up some loose ends before an absence from the office.
>>
>> R
>>
>> Robin Wilton
>>
>> On 12 Jan 2015, at 21:45, "Jim Fenton" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> Maybe I should be breaking these apart as Robin suggests, but for now I'll keep this in one reply:
>>
>> This thread raises several important topics… just as a practical matter, it might be worth trying to spin some of them off separately, so that we address them all, and minimise the risk of talking at cross-purposes.
>> It feels like it would be worth trying to put together some *very short* straw-man docs/pages/paragraphs to try and get a consensus version on specific points, so that we avoid re-hashing the same arguments/discussions over time, or at least have something we can refer to - and amend if necessary. I think this is aiming at the same end-point as Steve’s request for a statement of requirements, but will ensure we’re expressing our requirements in a consistent set of terms.
>>
>>
>> By the looks of it, these would make for a good starting point (I think the answers to most of these are implicit in various people’s contributions to the thread… but that doesn’t mean everyone agrees ;^)  ):
>>
>>
>> 1 - what do we mean by authentication and authorisation? Are there other decisions (e.g. access control, entitlement) which need to be called out explicitly? This reflects the purpose of Justin’s questions. Classically, the reason for authenticating a user is to answer a yes/no question (is this the person to whom this credential was originally issued); if yes, what do I want to do about it (at which point the further entitlements are usually determined by retrieving a user profile, ACL or whatever)?
>>
>> Access control and entitlement as distinct from authorisation? Is there a distinction, or are people just using different terminology?
>>
>> I think of authentication as providing more than a yes/no answer: it provides an identifier. If the relying party has enough information (perhaps on the basis of previous interactions) to authorize something with just that, fine. Otherwise some attributes are needed to make an authorisation decision.
>>
>>
>> However, as we know, these days access control and entitlement decisions also need to be made on the basis of input other than classic credentials, and that’s one of the two cores of this discussion, I believe.
>>
>> 2 - what’s the classic lifecycle of a credential - i.e. a artefact intended to provide evidence in support of an assertion of identity. (e.g. registration/verification/enrolment, credential issue, credential presentation/authentication, credential amendment/revocation/destruction…)?
>>
>>
>> Credential is another of those tricky words. Sometimes it means the same as an authentication token. Sometimes it has some attributes bound to it, which means it has both an authentication and attribute provision flavor to it. I find it simpler to talk about tokens, where one doesn't have to deal with revocation when some attribute (employment, for example) changes.
>>
>>
>>
>> 3 - How does (2) relate to other assertions (e.g. attribute assertions) we would like to make reliably?
>>
>>
>> With that starter set, I think we can confirm the subset of requirements that 800-63-1 still meets, and define the delta that requires new design.
>>
>> 4 - What’s the right way to update current thinking on LOAs, to account for the change Jim describes in his proposal - i.e., the case where "credentials (used in authentication) and attribute information (established through identity proofing) could be provided by different parties.”
>>
>> 5 - From Jim’s proposal: “Attribute reliability refers to the quality of the identity proofing process, as well as the strength of the binding of the identifying attributes to the authentication.” Do we need/want to expand on this a little? This seems to cater well for the case where, say, vehicle entitlements are being established so that they can be encapsulated in a driving licence. It’s not so clear how this addresses, say, third party assertions that do not arise from an identity proofing process - “I have no idea *who* this user is, but I can reliably assert the following about them: ... ”.
>>
>> You're right; that will need to be defined. But it should be possible to define analogous requirements to describe the strength of the binding to the token. When you show up to enroll at school, it should be possible to use your token to allow your school to make LOR 3 asserts that you're there student. But maybe remote students only get LOR 2?
>>
>> -Jim
>>
> vot mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/vot<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=uc913qsLA6bZ34rLfuSc3sig7ZcIykGDReZ73Wx21L0&e=>

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/vot<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=uc913qsLA6bZ34rLfuSc3sig7ZcIykGDReZ73Wx21L0&e=>

_______________________________________________
vot mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=AwICAg&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=4Q0ywmdZOmq4eJzFcK-ZUE2grM96iZWOPhoLSwpJKiI&s=uc913qsLA6bZ34rLfuSc3sig7ZcIykGDReZ73Wx21L0&e=

---

From: Steve Olshansky <[email-masked]>
Date: Tue, 13 Jan 2015 18:52:16 +0000

Here is the direct link to the document Peter referenced:
http://docs.oasis-open.org/trust-el/trust-el-framework/v1.0/cs01/trust-el-framework-v1.0-cs01.html

TC page:
https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=trust-el
	Steve

---

From: "Tarvi Martens" <[email-masked]>
Date: Thu, 15 Jan 2015 22:48:20 +0200

Hi,

The principle of Eurpean eIDAS eID recognition is mainly that „if you trust this in your country then other EU states shall it trust as well in their e-services“. Oh well, when it is sort of „registered and assessed“.

In general terms it comes down to community (read: RP-s) trust. For example hardly anyone would question Estonian ID-card for it security after living 13 years of harmless life,

Tarvi 

From: vot [mailto:[email-masked]] On Behalf Of Peter Alterman
Sent: Tuesday, January 13, 2015 8:00 PM
To: [email-masked]
Subject: Re: [VoT] vot Digest, Vol 5, Issue 6

regards,

Peter

Peter Alterman, Ph.D.

Chief Operating Officer

cell: 301-943-7452

Today's Topics:

---------- Forwarded message ----------
From: Robin Wilton <[email-masked]>
To: Colin Wallis <[email-masked]>
Cc: Jim Fenton <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 13 Jan 2015 09:31:59 +0000
Subject: Re: [VoT] capturing the threads of the discussion

R

Robin Wilton 

Cheers

Colin 

Thanks Jim,

R

Robin Wilton 

 

-Jim

All-

The wiki space for workshop attendees only, which you all have full edit access to and which is not publicly viewable, is athttps://tid.isoc.org/confluence/display/interfedgen/

<signature.asc>

---------- Forwarded message ----------
From: Steve Olshansky <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: 
Date: Tue, 13 Jan 2015 13:19:22 +0000
Subject: [VoT] VoT wiki
All-

---

From: Peter Alterman <[email-masked]>
Date: Thu, 15 Jan 2015 15:54:11 -0500

Hi Tarvi,

Agreed, and it gets more interesting this year and next, when the EC plans
to certify services against the Low and Substantial levels, leaving High to
the QCP (which includes Estonia, an example to us all).

Peter

On Thu, Jan 15, 2015 at 3:48 PM, Tarvi Martens <[email-masked]> wrote:

> Hi,
>
>
>
> The principle of Eurpean eIDAS eID recognition is mainly that „if you
> trust this in your country then other EU states shall it trust as well in
> their e-services“. Oh well, when it is sort of „registered and assessed“.
>
>
>
> In general terms it comes down to community (read: RP-s) trust. For
> example hardly anyone would question Estonian ID-card for it security after
> living 13 years of harmless life,
>
>
>
> Tarvi
>
>
>
> *From:* vot [mailto:[email-masked]] *On Behalf Of *Peter Alterman
> *Sent:* Tuesday, January 13, 2015 8:00 PM
> *To:* [email-masked]
> *Subject:* Re: [VoT] vot Digest, Vol 5, Issue 6
>
>
>
> ​Happy new year to you all.  I've been reading the mail but unable to
> break away long enough to comment until now. As I read it, the issue on the
> table is how to express trustworthiness.
>
>
>
> Well as Steve O pointed out in this attached email in November, the wiki
> set up for this work might be a place to start..
>
> 1 - what do we mean by authentication and authorisation? Are there other
> decisions (e.g. access control, entitlement) which need to be called out
> explicitly? This reflects the purpose of Justin’s questions. Classically,
> the reason for authenticating a user is to answer a yes/no question (is
> this the person to whom this credential was originally issued); if yes,
> what do I want to do about it (at which point the further entitlements are
> usually determined by retrieving a user profile, ACL or whatever)?
>
>
> With that starter set, I think we can confirm the subset of requirements
> that 800-63-1 still meets, and define the delta that requires new design.
>
>
>

---

From: Ken Dagg <[email-masked]>
Date: Wed, 21 Jan 2015 10:48:40 -0500

Peter,

It has taken me a while to get the time to read and reflect on what is
contained in your email.

Having finally thought about it, and the rest of the thread, I must say
bravo!

I believe that I agree fully with you: "the greatest opportunity open to us
is to find a way to normalize all the various community policies and
practices so that RPs can assess whether assertions issued under one
community's metrics align with their adopted risk mitigation requirements.
I think that has to be addressed in the context of how effective a
particular mitigation action is on a recognized threat vector."

If I am reading this correctly I think that you are saying is: how can
community 2 understand the risk mitigation processes undertaken by
community 1 so that it (community 2) can use the assertion made by
community 1 as one (possibly the sole) of the risk mitigation actions it
requires to allow some action.

In this context, 800-63 defines what the U.S. Federal Government expects to
have been done in order to accept assertions.

In my opinion, it is up to other communities to describe their specific
requirements to accept assertions and then compare and contrast those
requirements to 800-63. Once that analysis is completed these other
communities can make the decision as to whether they will accept assertions
based on 800-63.

Is there a normalized set of assertion requirements? I don't know. There
are a few communities that have described their requirements but, in my
opinion, I am not sure how easy it is to compare and contrast
these descriptions In a manner that might generate a normalized set. This
might be a fantastic Masters degree analysis that some enterprising student
might undertake. Or, if some federation could find the funding, that a
consultant could undertake.

Ken

On Tuesday, January 13, 2015, Peter Alterman <[email-masked]>
wrote:

> On Tue, Jan 13, 2015 at 8:19 AM, <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>>         [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>>
>> From: Robin Wilton <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> To: Colin Wallis <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> Cc: Jim Fenton <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> On 12 Jan 2015, at 23:43, "Colin Wallis" <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>> *From:* vot [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Robin
>> Wilton
>> *Cc:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> On 12 Jan 2015, at 21:45, "Jim Fenton" <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>>   By the looks of it, these would make for a good starting point (I
>> think the answers to most of these are implicit in various people’s
>> contributions to the thread… but that doesn’t mean everyone agrees ;^)  ):
>>
>>
>>
>>   3 - How does (2) relate to other assertions (e.g. attribute
>> assertions) we would like to make reliably?
>>
>>
>>
>> As we make progress on work items and are ready to move them to the
>> public wiki, I will be happy to do that. Our goal is of course to make as
>> much of our work as possible available to the public, but this restricted
>> wiki space gives us a place to work on things before revealing them to the
>> world.
>>
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> From: Steve Olshansky <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> To: "[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>> Cc:
>> On Jan 13, 2015, at 2:31 AM, Robin Wilton <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>>
>> > On 12 Jan 2015, at 23:43, "Colin Wallis" <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> >
>> >> There may be some jiggery pokery to get the folks on this list who
>> want to contribute (who were not attendees at Utrecht) access rights, but
>> it would seem to me to be the obvious starter option for a repository.
>> >> Cheers
>> >> Colin
>> >> From: vot [mailto:[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] On Behalf Of
>> Robin Wilton
>> >> Cc: [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> >> On 12 Jan 2015, at 21:45, "Jim Fenton" <[email-masked]
>> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>> >>
>> >> By the looks of it, these would make for a good starting point (I
>> think the answers to most of these are implicit in various people’s
>> contributions to the thread… but that doesn’t mean everyone agrees ;^)  ):
>> >>
>> >>
>> >> Access control and entitlement as distinct from authorisation? Is
>> there a distinction, or are people just using different terminology?
>> >>
>> >> 3 - How does (2) relate to other assertions (e.g. attribute
>> assertions) we would like to make reliably?
>> >>
>> >>
>> >> 4 - What’s the right way to update current thinking on LOAs, to
>> account for the change Jim describes in his proposal - i.e., the case where
>> > [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Scott Shorter <[email-masked]>
Date: Wed, 21 Jan 2015 14:16:53 -0500

Speaking of Estonia, we coincidentally just blogged on the topic of the
Estonian ID card and electronic residency program over at the Electrosoft
blog
<http://www.electrosoft-inc.com/electroblog/2015/1/21/when-trust-frameworks-collide-kantara-initiative-and-the-est.html>
.

Peter, thanks for bringing up the topic. Tarvi, welcome to the discussion!
-
Scott

On Thu, Jan 15, 2015 at 3:54 PM, Peter Alterman <
[email-masked]> wrote:

>> If Abbie was here he'd point you all to the one-to-one correlation
>> between trust and threat/threat vector mitigation.​ I recommend to you the
>> Third Deliverable of the OASIS Trust Elevation TC  - link provided upon
>> IMO, the greatest opportunity open to us is to find a way to normalize
>> all the various community policies and practices so that RPs can assess
>> whether assertions issued under one community's metrics align with their
>> adopted risk mitigation requirements. I think that has to be addressed in
>> the context of how effective a particular mitigation action is on a
>> recognized threat vector.   I would be most interested in your thoughts on
>> that problem.
>>
>>
>>
>> regards,
>>
>>
>>
>> Peter
>>
>>

-- 
==============================================================
*Scott Shorter, Principal Security Engineer*
Electrosoft *–* Fueling Customer Success Through Outstanding Value and
Trust!
*Woman-Owned, Minority-Owned Small Business | ISO 9001 | CMMI Level 2 *
1893 Metro Center Drive; Ste 228; Reston, VA 20190
(703) 437-9451 x21 (office);   (240) 994-7793 (cell)
[email-masked] (Email);   http://www.electrosoft-inc.com (Web)
==============================================================

---

From: "Jones, Mark B" <[email-masked]>
Date: Wed, 21 Jan 2015 19:52:22 +0000

Scott,

Thanks for that link.  I’m already considering a trip to the Estonian Embassy to get an ID.

From: vot [mailto:[email-masked]] On Behalf Of Scott Shorter
Sent: Wednesday, January 21, 2015 1:17 PM
To: Peter Alterman
Cc: Tarvi Martens; [email-masked]
Subject: Re: [VoT] vot Digest, Vol 5, Issue 6

Speaking of Estonia, we coincidentally just blogged on the topic of the Estonian ID card and electronic residency program over at the Electrosoft blog <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.electrosoft-2Dinc.com_electroblog_2015_1_21_when-2Dtrust-2Dframeworks-2Dcollide-2Dkantara-2Dinitiative-2Dand-2Dthe-2Dest.html&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=SVlU_6jS4i1rV5cW8wP8JiTdDQteuz_ktcTkYXM96E8&e=> .

-

Scott

On Thu, Jan 15, 2015 at 3:54 PM, Peter Alterman <[email-masked]> wrote:

Hi Tarvi,

Agreed, and it gets more interesting this year and next, when the EC plans to certify services against the Low and Substantial levels, leaving High to the QCP (which includes Estonia, an example to us all).

Peter

Peter Alterman, Ph.D.

Chief Operating Officer

cell: 301-943-7452

Hi,

Tarvi 

regards,

Peter

Peter Alterman, Ph.D.

Chief Operating Officer

cell: 301-943-7452

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/vot <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=J0XyFTFJ3b0p9pBGWRSRsWbF3Gk6ib4Ytx2-oXAosXM&e=> 
or, via email, send a message with subject or body 'help' to
        [email-masked]

Today's Topics:

---------- Forwarded message ----------
From: Robin Wilton <[email-masked]>
To: Colin Wallis <[email-masked]>
Cc: Jim Fenton <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 13 Jan 2015 09:31:59 +0000
Subject: Re: [VoT] capturing the threads of the discussion

R

Robin Wilton 

Cheers

Colin 

Thanks Jim,

R

Robin Wilton 

-Jim

All-

The wiki space for workshop attendees only, which you all have full edit access to and which is not publicly viewable, is athttps://tid.isoc.org/confluence/display/interfedgen/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__tid.isoc.org_confluence_display_interfedgen_&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=GyJh9gYzwCXsz2HYVIpFq4YOfrikT_9ictoeOHRfhZU&e=> 

The *PUBLIC* wiki space, containing the agenda, presentations, and contributions/references, is at
https://tid.isoc.org/confluence/display/interfed/ <https://urldefense.proofpoint.com/v2/url?u=https-3A__tid.isoc.org_confluence_display_interfed_&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=qFcVhwwFkYqkB2fUi4NGwAX7SYHej8GPfhEYXBwchdU&e=> 

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.internetsociety.org&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=-93VaDkUxmtE5Z1bXn8JqCD_607spkQHpSgYoKE1xbw&e=> 

<signature.asc>

_______________________________________________
Ideco-fab mailing list
[email-masked]
https://elists.isoc.org/mailman/listinfo/ideco-fab <https://urldefense.proofpoint.com/v2/url?u=https-3A__elists.isoc.org_mailman_listinfo_ideco-2Dfab&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=nrHHB33EZB_laqjm5e1ihOa8HqATX2jRYqi08yEDjNQ&e=> 

---------- Forwarded message ----------
From: Steve Olshansky <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: 
Date: Tue, 13 Jan 2015 13:19:22 +0000
Subject: [VoT] VoT wiki
All-

I setup a dedicated wiki space for use by this group. It is open to the world for viewing, but we can easily make restricted areas for the purpose of working on documents before publishing. Anyone would would like edit access is welcome to contact me directly (off-list).
https://tid.isoc.org/confluence/display/vot/VoT+Home <https://urldefense.proofpoint.com/v2/url?u=https-3A__tid.isoc.org_confluence_display_vot_VoT-2BHome&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=7yYLT9SVatLpaOEA-u4b6NSf7R9FWQuQfgBOQwRMP6g&e=> 
        Steve

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.internetsociety.org&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=-93VaDkUxmtE5Z1bXn8JqCD_607spkQHpSgYoKE1xbw&e=> 

On Jan 13, 2015, at 2:31 AM, Robin Wilton <[email-masked]> wrote:

> https://www.ietf.org/mailman/listinfo/vot <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=J0XyFTFJ3b0p9pBGWRSRsWbF3Gk6ib4Ytx2-oXAosXM&e=> 

_______________________________________________
vot mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vot <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=J0XyFTFJ3b0p9pBGWRSRsWbF3Gk6ib4Ytx2-oXAosXM&e=> 

_______________________________________________
vot mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/vot <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_vot&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=J0XyFTFJ3b0p9pBGWRSRsWbF3Gk6ib4Ytx2-oXAosXM&e=> 

-- 

Scott Shorter, Principal Security Engineer
Electrosoft – Fueling Customer Success Through Outstanding Value and Trust!
Woman-Owned, Minority-Owned Small Business | ISO 9001 | CMMI Level 2 
1893 Metro Center Drive; Ste 228; Reston, VA 20190
(703) 437-9451 x21 (office);   (240) 994-7793 (cell)
[email-masked] (Email);   http://www.electrosoft-inc.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.electrosoft-2Dinc.com_&d=AwMFaQ&c=6vgNTiRn9_pqCD9hKx9JgXN1VapJQ8JVoF8oWH1AgfQ&r=jgMu8DNgV_dycz0rYwkNbEQq36F0BI5_Zpblz7C5LhM&m=ZPfHQqAFOIM5YVJNqvQ6yVfh7tBXDqg0HI-Z8FG90iM&s=APHK6Vx7D2BpHCPDfoXTIS6APcCMrgn1WammeLhv33E&e=>  (Web)
==============================================================