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

From: Robin Wilton <[email-masked]>
Date: Mon, 12 Jan 2015 14:06:27 +0000

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)?
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…)? 

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: ... ”.

I think this might make it easier for us to put Steve’s requirements analysis and Ken’s liability model (which are both excellent, btw) into a shared conceptual framework, and also reduce the effort required to explain VoT to other stakeholders/contributors.

Hope this helps - 

R

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

On 10 Jan 2015, at 01:38, [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: A modest proposal to replace LOA (Richer, Justin P.)
>   2. Re: A modest proposal to replace LOA (Ken Dagg)
> 
> From: "Richer, Justin P." <[email-masked]>
> Subject: Re: [VoT] A modest proposal to replace LOA
> Date: 9 January 2015 22:59:56 GMT
> To: Joni Brennan <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, Stephen Wilson <[email-masked]>
> 
> 
> To me, a lot of it comes down to helping the RPs answer one question:
> 
> "Someone just logged in. Now what?"
> 
> I think that binning risk is part of the issue (as Steve states), but it's also (as a corollary) a matter of setting the context of an authentication. It's not just about "do I trust the display name" or whatever other attribute, but also about communicating to the RP what just happened. This can give the RP a chance at correctly deciding what to do about it.
> 
> There are really two parts of the whole conversation that I think getting wound up in each other:
>  - Things the RP needs to know about the IdP (i.e.: do I trust this IdP? what risk do I have in doing so?)
>  - Things the RP needs to know about the authentication transaction (i.e.: do I trust this log in?)
> 
> The VoT proposal tries to address this with the two different parts of the protocol: the vector as conveyed by the protocol, and the "trust mark provider" discovery portion.
> 
> To me, everything else is an aspect of answering these fundamental questions.
> 
>  -- Justin
> 
> On Jan 9, 2015, at 5:26 PM, Joni Brennan <[email-masked]> wrote:
> 
>> +1 to the suggestions so far and the comments around defining objectives.  
>> 
>> Apologies if this comment has already been made.  It may also be of use to pop up in the stack as well regarding objectives.  One layer abstraction removed from Steve's well pointed examples... I don't believe we need specific architecture for each but rather simply to be aware of the varying communities / priorities. 
>>   
>> LoAs (or something like VoTs) 
>> - Security
>> - Risk Management
>> - Interoperability (policy and tech) 
>> - Commercial (regulated / non)
>> - Government (public service - and what is a public services varies nationally)
>> 
>> Best Regards,
>> 
>> Joni Brennan
>> Kantara Initiative | Executive Director
>> email: joni @ kantarainitiative.org
>> 
>> Connecting Identity for a more trustworthy Internet - Overview
>> 
>> 
>> 
>> 
>> On Fri, Jan 9, 2015 at 2:19 PM, <[email-masked]> wrote:
>>  
>> If we're going to improve upon LOAs, then may I suggest the first thing to do is set out the objectives? 
>>  
>> - What is something like LOA really for? 
>> - Who uses a simplified "Risk Gauge", and how exactly? 
>> - How much original risk analysis is an RP expected to do before they bin their situation into Risk Gauge
>> - Is using a Risk Gauge supposed to save time in risk analysis?
>> - When an IdP claims a certain Risk Gauge, what does that really mean - contractually?
>> - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How much further analysis is needed before the RP can sign up the IdP? 
>> - If an IdP claims Risk Gauge X, how is that assured?
>>  
>> I suggest that LOAs were intended, net-net, to save time.  It was thought that by binning risk, RPs would be able to short list and then contract with suitable IdPs more quickly.  If there is any time saved in using LOAs then I suspect it gets gobbled up by the negotiating the fine print when signing up an IdP.  The very fact that RPs have asked for "LOA 2 and a half" tells us that the RP-IdP negotiation tends to be customised.  Than it, LOAs are difficult to standardise. 
>>  
>> Before we add dimensions, can we look at what its trying to achieve?
>>  
>> Cheers, 
>>  
>> Steve.
>>  
>> 
>> Stephen Wilson
>> Lockstep Group 
>> http://lockstep.com.au
>> Lockstep Consulting provides independent specialist advice and analysis 
>> on digital identity and privacy.  Lockstep Technologies develops unique 
>> new smart ID solutions that enhance privacy and prevent identity theft.
>>  
>>  
>>  
>> -----Original Message-----
>> From: "Jim Fenton" <[email-masked]>
>> Sent: Saturday, 10 January, 2015 7:49am
>> To: [email-masked]
>> Subject: [VoT] A modest proposal to replace LOA
>> 
>> I posted some ideas yesterday on a somewhat constrained possible
>> replacement for Levels of Assurance:
>> 
>> https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/
>> 
>> tl;dr: One dimension (LOA) isn't enough, but we don't want too many
>> dimensions or levels because that gets unwieldy. I'm proposing 3 levels
>> each of two dimensions: Level of Strength (authentication) and Level of
>> Reliability (attribute binding/proofing).
>> 
>> Any thoughts would be appreciated.
>> 
>> -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
>> 
>> 
>> _______________________________________________
>> vot mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/vot
> 
> 
> 
> 
> From: Ken Dagg <[email-masked]>
> Subject: Re: [VoT] A modest proposal to replace LOA
> Date: 10 January 2015 01:38:01 GMT
> To: "Richer, Justin P." <[email-masked]>
> Cc: Joni Brennan <[email-masked]>, "[email-masked]" <[email-masked]>, Stephen Wilson <[email-masked]>
> 
> 
> Justin,
> 
> IMO you have hit the nail on the head with those questions. At the end of the day, it is the RP's decision because, IMO, it is ultimately the RP that bears the consequences of something going wrong.
> 
> The interesting direction taken in the GC approach is the RP decides, based upon the GC standard and its supporting guidance, on their risk tolerance and categorizes it into a LOA bucket. The standard and guidance then identifies, based on that categorization, what the RP needs to do to mitigate that risk. Part of that mitigation could include accepting assertions from external organizations, such as authoritative parties, who provide assertions about something. It does not presume that any authoritative party will provide the "total" assertion. An important part of the standard is that it does not specify specific authoritative sources. Rather, it identifies what types of sources and how many of those sources should be used.
> 
> In this context, the answers to Steve's questions are, IMO, rather simple:
> - What is something like LOA really for? [[KD: IMO: LOAs are a simple means of communicating / characterizing a RP's identity assurance risk tolerance. From an IdP's perspective, it is a mechanism for specifying/communicating what mechanisms they have undertaken.]]
> - Who uses a simplified "Risk Gauge", and how exactly? [[see above]]
> - How much original risk analysis is an RP expected to do before they bin their situation into Risk Gauge [[KD: IMO a RP should not do any "original" risk analysis beyond the risk analysis they currently do to identify the risk of something going wrong based on an incorrect identity. It should be noted, the GC does not take into account the probability of something going wrong - they assume it is going to go wrong and identify the consequences of that happening.]]
> - Is using a Risk Gauge supposed to save time in risk analysis? [[KD: No. Risk analysis still takes the same  amount of time. And it still must be done.]]
> - When an IdP claims a certain Risk Gauge, what does that really mean - contractually? [[KD: IMO, it means that if an IdP can be shown not to have done everything that is specified to provide an assertion then they are liable for all damages. Otherwise, the RP is liable.]]
> - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How much further analysis is needed before the RP can sign up the IdP? [[KD: no further analysis should be required if the RP can trust that the IdP is telling the truth. An independent certification by an organization such as Kantara Initiative could provide that assurance. That being said, the RP should NOT be expected to use that assertion as the only thing required to mitigate their identity assurance risk. The RP needs to be in control of how much they need to do.]]
> - If an IdP claims Risk Gauge X, how is that assured? [[KD: as I said above, a certification by an independent third party could provide assurance to a RP.]]
> 
> What is important, IMO, about the Government of Canada's approach is that they have looked at the whole situation from the RP's perspective ... From the RP being in control of their destiny. It is their problem if something goes wrong. That, and they assume something will go wrong without taking into account the probability of it occuring - it is of little comfort to users to have an RP say, after a break, "we considered that risk but did not think it was too likely to occur."
> 
> Ken
> 
> On Friday, January 9, 2015, Richer, Justin P. <[email-masked]> wrote:
> To me, a lot of it comes down to helping the RPs answer one question:
> 
> "Someone just logged in. Now what?"
> 
> I think that binning risk is part of the issue (as Steve states), but it's also (as a corollary) a matter of setting the context of an authentication. It's not just about "do I trust the display name" or whatever other attribute, but also about communicating to the RP what just happened. This can give the RP a chance at correctly deciding what to do about it.
> 
> There are really two parts of the whole conversation that I think getting wound up in each other:
>  - Things the RP needs to know about the IdP (i.e.: do I trust this IdP? what risk do I have in doing so?)
>  - Things the RP needs to know about the authentication transaction (i.e.: do I trust this log in?)
> 
> The VoT proposal tries to address this with the two different parts of the protocol: the vector as conveyed by the protocol, and the "trust mark provider" discovery portion.
> 
> To me, everything else is an aspect of answering these fundamental questions.
> 
>  -- Justin
> 
> On Jan 9, 2015, at 5:26 PM, Joni Brennan <[email-masked]> wrote:
> 
>> +1 to the suggestions so far and the comments around defining objectives.  
>> 
>> Apologies if this comment has already been made.  It may also be of use to pop up in the stack as well regarding objectives.  One layer abstraction removed from Steve's well pointed examples... I don't believe we need specific architecture for each but rather simply to be aware of the varying communities / priorities. 
>>   
>> LoAs (or something like VoTs) 
>> - Security
>> - Risk Management
>> - Interoperability (policy and tech) 
>> - Commercial (regulated / non)
>> - Government (public service - and what is a public services varies nationally)
>> 
>> Best Regards,
>> 
>> Joni Brennan
>> Kantara Initiative | Executive Director
>> email: joni @ kantarainitiative.org
>> 
>> Connecting Identity for a more trustworthy Internet - Overview
>> 
>> 
>> 
>> 
>> On Fri, Jan 9, 2015 at 2:19 PM, <[email-masked]> wrote:
>>  
>> If we're going to improve upon LOAs, then may I suggest the first thing to do is set out the objectives? 
>>  
>> - What is something like LOA really for? 
>> - Who uses a simplified "Risk Gauge", and how exactly? 
>> - How much original risk analysis is an RP expected to do before they bin their situation into Risk Gauge
>> - Is using a Risk Gauge supposed to save time in risk analysis?
>> - When an IdP claims a certain Risk Gauge, what does that really mean - contractually?
>> - If an RP at Gauge X finds an IdP at Gauge X (or higher), what's next? How much further analysis is needed before the RP can sign up the IdP? 
>> - If an IdP claims Risk Gauge X, how is that assured?
>>  
>> I suggest that LOAs were intended, net-net, to save time.  It was thought that by binning risk, RPs would be able to short list and then contract with suitable IdPs more quickly.  If there is any time saved in using LOAs then I suspect it gets gobbled up by the negotiating the fine print when signing up an IdP.  The very fact that RPs have asked for "LOA 2 and a half" tells us that the RP-IdP negotiation tends to be customised.  Than it, LOAs are difficult to standardise. 
>>  
>> Before we add dimensions, can we look at what its trying to achieve?
>>  
>> Cheers, 
>>  
>> Steve.
>>  
>> 
>> Stephen Wilson
>> Lockstep Group 
>> http://lockstep.com.au
>> Lockstep Consulting provides independent specialist advice and analysis 
>> on digital identity and privacy.  Lockstep Technologies develops unique 
>> new smart ID solutions that enhance privacy and prevent identity theft.
>>  
>>  
>>  
>> -----Original Message-----
>> From: "Jim Fenton" <[email-masked]>
>> Sent: Saturday, 10 January, 2015 7:49am
>> To: [email-masked]
>> Subject: [VoT] A modest proposal to replace LOA
>> 
>> I posted some ideas yesterday on a somewhat constrained possible
>> replacement for Levels of Assurance:
>> 
>> https://altmode.wordpress.com/2015/01/08/level-of-assurance-alternatives-a-modest-proposal/
>> 
>> tl;dr: One dimension (LOA) isn't enough, but we don't want too many
>> dimensions or levels because that gets unwieldy. I'm proposing 3 levels
>> each of two dimensions: Level of Strength (authentication) and Level of
>> Reliability (attribute binding/proofing).
>> 
>> Any thoughts would be appreciated.
>> 
>> -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
>> 
>> 
>> _______________________________________________
>> 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: Jim Fenton <[email-masked]>
Date: Mon, 12 Jan 2015 13:44:56 -0800

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

---

From: Robin Wilton <[email-masked]>
Date: Mon, 12 Jan 2015 22:22:13 +0000

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.

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

---

From: Colin Wallis <[email-masked]>
Date: Mon, 12 Jan 2015 23:43:15 +0000

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,

R

Robin Wilton

-Jim

Subject: [Ideco-fab] About the InterFed+Attributes wiki
From: Steve Olshansky <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 20 Nov 2014 14:33:41 +0000
List-Id: <ideco-fab.elists.isoc.org>

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

---

From: Robin Wilton <[email-masked]>
Date: Tue, 13 Jan 2015 09:31:59 +0000

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]] 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,

R

Robin Wilton

-Jim
All-

--
Steve Olshansky
Trust & Identity Program Lead
Internet Society
www.internetsociety.org<http://www.internetsociety.org>

<signature.asc>
_______________________________________________
Ideco-fab mailing list
[email-masked]<mailto:[email-masked]>
https://elists.isoc.org/mailman/listinfo/ideco-fab

---

From: Steve Olshansky <[email-masked]>
Date: Tue, 13 Jan 2015 13:19:22 +0000

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

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

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