[WG-IDAssurance] IAWG Meeting notes 2014-05-15
Andrew Hughes
Andrew Hughes CISM CISSP
Independent Consultant
In Turn Information Management Consulting
+1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHu...@gmail.com
ca.linkedin.com/pub/andrew-hughes/a/58/682/
Identity Management | IT Governance | Information Security
Schreiner, Susan F.
On the topic of attribute “assurance” I recommend a very interesting paper I just finished reading – citation below.
Thomas, I.; Meinel, C., "An Attribute Assurance Framework to Define and Match Trust in Identity Attributes," Web
Services (ICWS), 2011 IEEE International Conference on , vol., no., pp.580,587, 4-9 July 2011
doi: 10.1109/ICWS.2011.80
They define an framework where both Trust in the Attribute + Trust in the IdP = Identity Assurance….
Thanks,
Susan
Scott Shorter
- Identity Attributes by themselves don't have levels of assurance (not a new idea), but they do have metadata (data about the attribute) that can convey:
- Temporal characteristics of the attribute (when an address was valid, when a name changed, etc)
- Freshness of the attribute value - (last refresh as well as what standards of refresh this attribute provider follows)
- Verification method that's been applied to this attribute value (e.g. verification against 3rd party data or an authoritative source)
- Several work efforts now or recently on this topic
- IDESG attributes working group
- Kantara attributes in motion working group (whose roadmap claims credit for V1.0 of the Internet2 attribute metadata registry )
- Peter Alterman's earlier work on this topic (link, anyone?)
- And thank you Susan for: Thomas, I.; Meinel, C., "An Attribute Assurance Framework to Define and Match Trust in Identity Attributes," (yours for a mere $19!)
_______________________________________________
WG-IDAssurance mailing list
WG-IDAs...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-idassurance
Scott Shorter, Principal Security Engineer, Electrosoft Services Inc.
Schreiner, Susan F.
J I’ve attached Peter’s work to which I think you’re referring.
Sorry I couldn’t send the actual Thomas/Meinel article, but subscriptions are subscriptions….
Thanks,
Susan
From: wg-idassura...@kantarainitiative.org [mailto:wg-idassura...@kantarainitiative.org]
On Behalf Of Scott Shorter
Sent: Thursday, May 15, 2014 1:37 PM
To: Andrew Hughes
Cc: IAWG
Subject: Re: [WG-IDAssurance] IAWG Meeting notes 2014-05-15
We did agree to discuss assurance of attributes further, so I'll jump in.
Points discussed during the call:
· Identity Attributes by themselves don't have levels of assurance (not a new idea), but they do have metadata (data about the attribute) that can convey:
o Temporal characteristics of the attribute (when an address was valid, when a name changed, etc)
o Freshness of the attribute value - (last refresh as well as what standards of refresh this attribute provider follows)
o Verification method that's been applied to this attribute value (e.g. verification against 3rd party data or an authoritative source)
· Several work efforts now or recently on this topic
o IDESG attributes working group
o Kantara attributes in motion working group (whose roadmap claims credit for V1.0 of the Internet2 attribute metadata registry )
o Peter Alterman's earlier work on this topic (link, anyone?)
o And thank you Susan for: Thomas, I.; Meinel, C., "An Attribute Assurance Framework to Define and Match Trust in Identity Attributes," (yours for a mere $19!)
Scott
Richard G. WILSHER (Zygma CEO)
Don’t we need to make this distinction and then set a scope accordingly? Are we addressing just one of these two topics or both (in which case that must be two separate streams – they do not intermix).
And if poor ol’ Rich Furr is to be talking to the Leadership Council next Wednesday, how does this discussion and Andrew’s string of questions help Rich make any assertive statement, other than “it’s still up for grabs”?
R
Richard G. WILSHER
Founder & CEO
1993 - Twenty years of independent operations – 2013
O: +1 714 965 99 42
M: +1 714 797 99 42
E: R...@Zygma.biz
W: www.Zygma.biz
From: wg-idassura...@kantarainitiative.org [mailto:wg-idassura...@kantarainitiative.org] On Behalf Of Scott Shorter
Sent: Thursday, 15 May, 2014 17:37
To: Andrew Hughes
Cc: IAWG
Subject: Re: [WG-IDAssurance] IAWG Meeting notes 2014-05-15
We did agree to discuss assurance of attributes further, so I'll jump in.
Points discussed during the call:
- Identity Attributes by themselves don't have levels of assurance (not a new idea), but they do have metadata (data about the attribute) that can convey:
- Temporal characteristics of the attribute (when an address was valid, when a name changed, etc)
- Freshness of the attribute value - (last refresh as well as what standards of refresh this attribute provider follows)
- Verification method that's been applied to this attribute value (e.g. verification against 3rd party data or an authoritative source)
- Several work efforts now or recently on this topic
- IDESG attributes working group
- Kantara attributes in motion working group (whose roadmap claims credit for V1.0 of the Internet2 attribute metadata registry )
- Peter Alterman's earlier work on this topic (link, anyone?)
Scott
Richard G. WILSHER (Zygma CEO)
Richard G. WILSHER
Founder & CEO
1993 - Twenty years of independent operations – 2013
O: +1 714 965 99 42
M: +1 714 797 99 42
E: R...@Zygma.biz
W: www.Zygma.biz
Schreiner, Susan F.
Scott – I think Peter also either presented or discussed something on attribute “assurance” this week (or last)? Peter?
Thanks,
Susan
From: Schreiner, Susan F.
Sent: Thursday, May 15, 2014 1:47 PM
To: 'Scott Shorter'; Andrew Hughes
Cc: IAWG
Subject: RE: [WG-IDAssurance] IAWG Meeting notes 2014-05-15
J I’ve attached Peter’s work to which I think you’re referring.
Sorry I couldn’t send the actual Thomas/Meinel article, but subscriptions are subscriptions….
Thanks,
Susan
From:
wg-idassura...@kantarainitiative.org [mailto:wg-idassura...@kantarainitiative.org]
On Behalf Of Scott Shorter
Sent: Thursday, May 15, 2014 1:37 PM
To: Andrew Hughes
Cc: IAWG
Subject: Re: [WG-IDAssurance] IAWG Meeting notes 2014-05-15
We did agree to discuss assurance of attributes further, so I'll jump in.
Points discussed during the call:
· Identity Attributes by themselves don't have levels of assurance (not a new idea), but they do have metadata (data about the attribute) that can convey:
o Temporal characteristics of the attribute (when an address was valid, when a name changed, etc)
o Freshness of the attribute value - (last refresh as well as what standards of refresh this attribute provider follows)
o Verification method that's been applied to this attribute value (e.g. verification against 3rd party data or an authoritative source)
· Several work efforts now or recently on this topic
o IDESG attributes working group
o Kantara attributes in motion working group (whose roadmap claims credit for V1.0 of the Internet2 attribute metadata registry )
o Peter Alterman's earlier work on this topic (link, anyone?)
o And thank you Susan for: Thomas, I.; Meinel, C., "An Attribute Assurance Framework to Define and Match Trust in Identity Attributes," (yours for a mere $19!)
Scott
Robin Wilton
much the same topic... with Ken Dagg and Nishant leading the "there's no
such thing as LOA for Attributes" camp, and me trying to argue that
one's interpretation of attribute assertions can be non-binary, and can
benefit from supporting data about freshness, authoritative source etc.
I think your distinction between identity attributes and characteristic
attributes may well be useful - but my starting point is that an
attribute is anything that can be predicated of an individual (or
thing).
R
> cid:image0...@01CEC9E9.E9D38700
> 1993 - Twenty years of independent operations – 2013
>
> O: +1 714 965 99 42
> M: +1 714 797 99 42
> E: <mailto:R...@Zygma.biz> R...@Zygma.biz
> W: <http://www.zygma.biz/> www.Zygma.biz
>
>
>
> From: wg-idassura...@kantarainitiative.org
> [mailto:wg-idassura...@kantarainitiative.org] On Behalf Of Scott
> Shorter
> Sent: Thursday, 15 May, 2014 17:37
> To: Andrew Hughes
> Cc: IAWG
> Subject: Re: [WG-IDAssurance] IAWG Meeting notes 2014-05-15
>
>
>
> We did agree to discuss assurance of attributes further, so I'll jump in.
>
>
>
> Points discussed during the call:
>
> * Identity Attributes by themselves don't have levels of assurance
> (not a new idea
> <http://info.idmanagement.gov/2012/05/why-loa-for-attributes-dont-really.html>
> ), but they do have metadata (data about the attribute) that can convey:
>
> * Temporal characteristics of the attribute (when an address was
> valid, when a name changed, etc)
> * Freshness of the attribute value - (last refresh as well as what
> standards of refresh this attribute provider follows)
> * Verification method that's been applied to this attribute value
> (e.g. verification against 3rd party data or an authoritative source)
>
> * Several work efforts now or recently on this topic
>
> * IDESG attributes working group
> * Kantara attributes in motion working group (whose roadmap claims
> credit for V1.0 of the Internet2 attribute metadata registry
> <https://spaces.internet2.edu/display/scalepriv/Attribute+Registry+Overview>
> )
> * Peter Alterman's earlier work on this topic (link, anyone?)
> * And thank you Susan for: Thomas, I.; Meinel, C., "An Attribute
> Assurance Framework to Define and Match Trust in Identity Attributes,"
> (yours for a mere $19
> <http://www.computer.org/csdl/proceedings/icws/2011/4463/00/4463a580-abs.html>
> !)
>
> What am I forgetting?
>
> --
>
> Scott
>
>
>
> On Thu, May 15, 2014 at 1:08 PM, Andrew Hughes
> <andrewhu...@gmail.com> wrote:
>
> Yes, there was a meeting today, it was quorate.
>
>
>
> Notes here:
>
> https://kantarainitiative.org/confluence/x/KQMaB
>
>
>
> Major discussion on the topic of Assurance Levels as related to
> Attributes.
>
>
>
> andrew.
>
>
> Andrew Hughes CISM CISSP
> Independent Consultant
> In Turn Information Management Consulting
>
> +1 250.888.9474 <tel:%2B1%20250.888.9474>
> 1249 Palmer Road,
> Victoria, BC V8P 2H8
> <mailto:AndrewHu...@gmail.com> AndrewHu...@gmail.com
> ca.linkedin.com/pub/andrew-hughes/a/58/682/
> Identity Management | IT Governance | Information Security
>
>
> _______________________________________________
> WG-IDAssurance mailing list
> WG-IDAs...@kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-idassurance
>
>
>
>
>
>
>
> --
> Scott Shorter, Principal Security Engineer, Electrosoft Services Inc.
>
> ssho...@electrosoft-inc.com O: 703-437-9451 x21 M: 240-994-7793
>
> _______________________________________________
> WG-IDAssurance mailing list
> WG-IDAs...@kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-idassurance
> Email had 1 attachment:
> + image001.jpg
> 3k (image/jpeg)
Robin Wilton
+44 (0)705 005 2931
swi...@lockstep.com.au
I offer a general analysis that pigeonholing risk into generic LOAs is never going to work (not at high assurance anyway) regardless of whether we're talking about "identities" or "attributes".
http://lockstep.com.au/blog/2011/04/08/i-dont-get-loas
On the specific issue of Attributes vs Identities ... at a deeper abstraction, they're both just pieces of data about a subject vouched for by an authority. The question of pedigree of that data is the same for "id" or "attribute". And again, I think the case by case answer to the pedigree question cannot be pigeonholed.
Cheers,
Steve.
Steve Wilson
Lockstep
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.
Andrew Hughes
--
Andrew Hughes CISM CISSP
Independent Consultant
In Turn Information Management Consulting
1249 Palmer Road,
Victoria, BC V8P 2H8
Rainer Hoerbe
Patrick Curry
regards,
Patrick Curry
Director
Clarion Identity Ltd
M: +44 786 024 9074
T: +44 1980 620606
patric...@clarionidentity.com
Natale, Bob
Hi Andrew,
I am generally +1 wrt your thinking … but coherence (completeness and consistency) on this topic cannot be achieved without more explanation … I won’t go into the requisite level of detail here, but will add a few clarifying points:
- We need to distinguish between “attribute assurance” and “attribute strength”:
-- Attribute strength conveys the utility of an attribute (or attribute set or bundle) for a given purpose (e.g., identity resolution)
--- E.g. (and totally notional), in some hypothetical “scoring” system for person-centric identity resolution purposes, “Full Birth Name” might carry a strength of 1 and “Full Current Address” might carry a strength of .1, but together they might carry a strength score of 1.25.
-- Attribute assurance (which we can think of as similar to a data veracity requirement) conveys the trustability of an actual attribute value from a given source (attribute provider)
-- These two constructs are orthogonal but are often interdependent in practice (since, in the general case, high-strength attributes typically require greater assurance than low-strength attributes).
- Then, for any given interoperating identity/trust ecosystem, you need an “identity attribute catalog” that might structure the universe of possible attributes across categories (e.g., biographic, biometric, social/contextual, etc.), as “composite” attributes (e.g., “Full Name”) comprised of “component” attributes (e.g., “First Name”, “Surname”, “Suffix”) binned by “qualifier” types (e.g., “Birth”, “Legal”, “Maiden”, “Alias”, “Current”, “Previous”, etc.). This catalog is the primary artifact requiring standardization (to include extensibility mechanisms).
- The categories, composites, components, and qualifiers (possibly among other factors) all contribute to the attribute/attribute set strength score. Multiple scoring systems (e.g., with different factors, values, weights, and calculation algorithms) are possible over the same sets of attributes depending upon application environment specifics.
- The specification of identity attribute set requirements via the catalog model is sufficient for a high degree of interoperability and functional value for both identity establishment and identity verification operations across RPs, IdPs, TPs, CSPs, etc. That holds independently from any given scoring system.
- The scoring model can be used – within a given ecosystem and application context – to provide more advanced/granular operations … e.g., dynamic trust elevation operations, or levels of assurance … but is probably too much of a reach for current discussion in this forum.
So, to respond to your later request for input on “the question of Attributes”, I do support continuation of the attribute work within the IdAWG (IAWG) with a primary focus on specification of a baseline identity attribute catalog as an early deliverable … the catalog is the foundation for avoiding (or repairing) the “fragmentation” that Patrick mentioned I a later post as well. The catalog work could leverage (and eventually expand) the Kantara/Internet2 Attribute Registry work (http://kantarainitiative.org/confluence/download/attachments/65667290/attRegOverview.pdf) … but should focus on high-level structure before delving into OWL formulations, IMHO.
Avanti,
BobN
Myisha Frazier-McElveen
Ken Dagg
Faut, Nathan E
Bob, Andrew and IAWG compatriots –
I thought about this subject a few years ago and generated the following thinking. I pass it along FWIW. YMMV.
=-=-=-=-=-=-=-
Malcolm, Peter, Noel, Don, and Tom –
Hi again. I am resurrecting this “old” thread because I have put some additional “copious free time” thought into what I outlined below. Here is the current state of my thinking:
Thanks to Malcolm at lunch today for some of these new considerations.
Setup an identity-attribute database with fields including:
Attribute – source [e-mail/in-person/etc.] – original AAL – original timestamp – degradation time period (could be attribute-specific!) – current AAL [Attribute Assurance Level] -
[Copying and pasting from the previous message I sent to here:]
Name [current Attribute Assurance Level (cAAL)- low for e-mail or remote: high for in-person: degrades to med if attribute is over a year (or other defined time period) old]
BusAddress [cAAL- low for e-mail or remote: high for in-person: degrades to med if attribute is over a year (or other defined time period) old]
BusPhone [cAAL- low for e-mail or remote: high for in-person: degrades to med if attribute is over a year (or other defined time period) old]
BusEmail [cAAL- low for e-mail or remote: high for in-person: degrades to med if attribute is over a year (or other defined time period) old]
BusInfoValidated (Y/N) [cAAL- low for N, high for Yes if under the degradation period, med if over the degradation period]
IDProof1 (list of nine approved and accepted documents: e.g., SSN doc, utility bill, passport, state driver’s license, non-US driver’s license w/ photo, etc.) [cAAL- low for source<>InPersonProof - N, hi for source =InPersonProof AND under the degradation period – Y, med for source=InPersonProof AND over degradation period]
IDProof2 (same list) [see IDProof1]
IDProof3 (same list, include 10th entry N/A) [see IDProof1]
OutofBandProof (Y/N) [AAL- low for N; hi for Y AND under the degradation period, med for Y and over the degradation period]
InPersonProof (Y/N) [see OutofBandProof]
BackgroundChk (Y/N) [see OutofBandProof]
IDusage1 (list, e.g., AuthN-LOA#, sign docs, encrypt msgs, other) [no AAL]
IDusage2 (same list as IDusage1) [no AAL]
IDusage3 (same list as IDusage1) [no AAL]
[and others]
For FederationX, these attributes must be gathered for each e-cred, and must be maintained either in the certificate or on the LDAP server.
FederationX may now start to define LOA1 as the following attributes:
Name
BusAddress
BusPhone
BusEmail
BusInfoValidated - N
InPersonProof – N
IDusage1 – AuthN-LOA1
LOA2 could be:
(all of LOA1 attributes; change IDusage1 to AuthN-LOA2, plus)
BusInfoValidated –Y
OutofBandProof – Y
<may include all attributes over degradation period/s>
LOA3 could be:
(all of LOA2 attributes; change IDusage1 to AuthN-LOA3, plus)
BackgroundChk – Y
<other attributes under degradation period>
IDusage2 – sign docs
LOA4 could be:
(all of LOA3 attributes; change IDuage1 to AuthN-LOA4, change OutofBandProof to N, plus)
InPersonProof – Y
<other attributes under degradation period/s>
IDusage3 – encrypt msgs
This is ALL off the top of my head. But I think this hits a number of things that the attribute space is aiming to achieve in some form or other.
=-=-=-=-=-=-=-
Best regards,
-Nathan
=-=-=-=-=-=-=-=-
Nathan Faut, Manager, IT Attestation, Federal Practice, KPMG LLP
1676 International Drive
Suite 1200
Mclean, VA 22102
office: 703-286-6883
mobile: 301-335-2656
FAX: 202-403-3126
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. When addressed to our clients any opinions or advice contained in this email are subject to the terms and conditions expressed in the governing KPMG client engagement letter.
***********************************************************************
swi...@lockstep.com.au
Thanks Andrew,
I completely agree with the idea that RPs will determine what they need to know about a Subject in order to do business in a given setting. The RP should be able to shop around for sourced of attribute information that meets their needs.
The question is whether we can characterise and "market" attribute information according to generic levels of assurance 1, 2, 3 or 4.
At low LOAs, the problem is trivial. At LOA 1, the IdP doesn't know who you are, and the RP doesn't care who you are. But at high LOAs, I believe that the marginal benefit of starting a negotiation between RP and IdP/AP with a generic benchmark of LOA 4 is of no practical benefit.
I have two questions to try and sharpen this debate:
1. Is there an example anywhere in the world of an LOA 4 RP accepting off-the-shelf an LOA 4 Identity? I know of none. At high LOA, the identification is always customised (in keeping with Risk Management orthodoxy which says you must analyse your own local risk for yourself; you cannot outsource risk management).
2. If we think that a generic LOA 3 or 4 pigeonhole is feasible, can someone explain what we're doing differently in IDAM today compared with Big CAs 15 years ago? The Big CA business model back then was predicated on a generic passport-grade personal identity certificate that they thought was going to be useful for a wide range of transaction types and RPs. But the total cost of risk management when it includes weighing and understanding the Ts&Cs imposed by the CAs proved to be excessive. So looking at LOA 3 and 4 IdPs today, what are the actual liability arrangements on offer, and are the terms any more attractive than the basically useless vanilla warranties offered by ye olde CAs?
In high risk transactions, my thesis is there is no net savings to an RP in relying on an externally issued generic identity, when the RP has to invest untold time and effort understanding the basis for the external identification process. It is less expensive and less risky for the RP to do its own identification and identity issuance.
swi...@lockstep.com.au
I don't see that finessing the difference between "identity" and "attribute" let alone breaking out even more types of Attributes is helpful. Many people actually say they wish we didn't use the word "identity" in describing the engineering problem of IdM.
Thinking like a computer scientist, why don't we abstract the things we're trying to deal with, down to the lowest common denominator, and create methods to deal with the most basic components?
The core problem in authentication is this: What does Alice need to know about Bob in order to accept a transaction or message from Bob? This is how the APEC Authentication WG framed the question over 10 years ago.
The common thing about "identities" and "attributes" (or claims or assertions) is this: they're all just pieces of information (or signals if you will) that help Relying Parties make the authentication decision.
See also http://lockstep.com.au/blog/2013/02/19/identity-algebra
Cheers,
Steve.
Steve Wilson
Lockstep
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.
Colin Wallis
Date: Sat, 17 May 2014 14:50:12 +1000
From: swi...@lockstep.com.au
To: wg-idas...@kantarainitiative.org
Subject: [WG-IDAssurance] Feasibility of high LOAs [was: IAWG Meeting notes 2014-05-15]
Smedinghoff, Tom
At the risk of jumping into a thread that I haven’t been following closely, Steve’s comment caught my attention, as it bears directly on an issue I have been looking at.
I think Steve is absolutely right. As I analyze these IdM issues from a legal, contractual, and trust framework perspective, it seems to me that what we are looking at is, at its essence, nothing more than an exchange of information. Whether we label that information as an “identity”, an “attribute” or something else is really not that important. It would seem that the basic concerns are simply: (1) what information does the RP need to know about a subject?, (2) is that information sufficiently reliable for the RP’s purposes?, and (3) is that information accurately communicated to the RP?.
Of course we also need to know what privacy rules apply to that information, but that issue is also independent of what IdM label we apply to the information.
As I work through this from a legal perspective, comments more than welcome.
Thanks,
Tom
Thomas J. Smedinghoff
Edwards Wildman Palmer LLP
225 W. Wacker Drive
Chicago, Illinois 60606
Office: +1 312-201-2021
Mobile: +1 312-545-1333
tsmedi...@edwardswildman.com
_______________________
Edwards Wildman Palmer LLP has offices in Boston, Chicago, Hartford, Hong Kong, Istanbul, London, Los Angeles, Miami, Morristown NJ, New York, Orange County, Providence, Stamford, Tokyo, Washington DC and West Palm Beach. For more information visit edwardswildman.com.
CONFIDENTIALITY NOTICE
This e-mail message from Edwards Wildman Palmer LLP, Edwards Wildman Palmer UK LLP, Edwards Wildman Palmer, a Hong Kong firm of solicitors, and Edwards Wildman Danismanlik Hizmetleri Avukatlik Ortakligi, a registered foreign attorney partnership, is intended only for the individual or entity to which it is addressed. This e-mail may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you received this e-mail by accident, please notify the sender immediately and destroy this e-mail and all copies of it. We take steps to protect against viruses but advise you to carry out your own checks and precautions as we accept no liability for any which remain. We may monitor emails sent to and from our server(s) to ensure regulatory compliance to protect our clients and business. Edwards Wildman Palmer UK LLP is a limited liability partnership registered in England (registered number OC333092) and is authorised and regulated by the Solicitors Regulation Authority (SRA) and operates an SRA standard complaints procedure (see here). A list of members' names and their professional qualifications may be inspected at our registered office, Dashwood, 69 Old Broad Street, London EC2M 1QS, UK, telephone +44 207 583 4055.
Disclosure Under U.S. IRS Circular 230: Edwards Wildman Palmer LLP informs you that any tax advice contained in this communication, including any attachments, was not intended or written to be used, and cannot be used, for the purpose of avoiding federal tax related penalties or promoting, marketing or recommending to another party any transaction or matter addressed herein.
Susan Morrow
Andrew Hughes
_______________________
Edwards Wildman Palmer LLP has offices in Boston, Chicago, Hartford, Hong Kong, Istanbul, London, Los Angeles, Miami, Morristown NJ, New York, Orange County, Providence, Stamford, Tokyo, Washington DC and West Palm Beach. For more information visit edwardswildman.com.
CONFIDENTIALITY NOTICE
This e-mail message from Edwards Wildman Palmer LLP, Edwards Wildman Palmer UK LLP, Edwards Wildman Palmer, a Hong Kong firm of solicitors, and Edwards Wildman Danismanlik Hizmetleri Avukatlik Ortakligi, a registered foreign attorney partnership, is intended only for the individual or entity to which it is addressed. This e-mail may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you received this e-mail by accident, please notify the sender immediately and destroy this e-mail and all copies of it. We take steps to protect against viruses but advise you to carry out your own checks and precautions as we accept no liability for any which remain. We may monitor emails sent to and from our server(s) to ensure regulatory compliance to protect our clients and business. Edwards Wildman Palmer UK LLP is a limited liability partnership registered in England (registered number OC333092) and is authorised and regulated by the Solicitors Regulation Authority (SRA) and operates an SRA standard complaints procedure (see here). A list of members' names and their professional qualifications may be inspected at our registered office, Dashwood, 69 Old Broad Street, London EC2M 1QS, UK, telephone +44 207 583 4055.
Disclosure Under U.S. IRS Circular 230: Edwards Wildman Palmer LLP informs you that any tax advice contained in this communication, including any attachments, was not intended or written to be used, and cannot be used, for the purpose of avoiding federal tax related penalties or promoting, marketing or recommending to another party any transaction or matter addressed herein.
--
Susan Morrow
j stollman
Jeff Stollman
stoll...@gmail.com
1 202.683.8699
Ken Dagg
--
swi...@lockstep.com.au
Thanks Colin.
Obviously, please correct me if I'm wrong, but with New Zealand's RealMe, my understanding is that banks use it to help verify the identity of customers when registering/enrolling them for new accounts. Once someone passes the banking registration rules, they are given a new account and credentials for logging on subsequently. That is, the banks still issue their own identities. I don't believe RealMe is used as the identity/credential for routinely logging on to a bank.
Regarding Ts&Cs, is it the case that a bank can use RealMe, with no other data, to verify a new customer and, for instance, create a new bank account? That is, does RealMe warant a customer's identity to the extent that no other identifying details need to be checked by a bank?
Cheers,
Steve.
swi...@lockstep.com.au
All true Jeff.
So, back to my point about why are we over-cooking the differences between "identity" and "attributes", I still don't see any reason to create global definitions and distinctions.
In each transaction setting, the RP will need to know certain things about the Subject. Some of these things get bundled together into data structures that are conveniently called "identities". And some of these things constitute Personally Identifiable Information and as such are subject to other data protection regulations.
But the core IDAM engineering challenge is to improve the reliability and availability of the data that RPs need to know about Subjects, and to enhance the pedigree of that data by making it clear which authorities have vouched for it. As a computing problem, we can solve these problems without reference to subtle and controversial semantics about "identity" and "attributes".
"Identity" always means different things to different Relaying Parties.
See also http://lockstep.com.au/blog/2012/08/25/surfacing-identity
Good engineering means looking for common denominators. We need to reduce the abstract to the concrete. We should drop down a level, and in IDAM deal not with identities but with attributes. All IdPs are really only Attribute Providers.
Cheers,
Steve.
Ken Dagg
To me this is the challenge that the industry is facing today and, unfortunately, in my opinion, only private sector organizations are playing the game.
swi...@lockstep.com.au
Ken,
I think that's spot-on.
The "Identity Providers" in government often seem oblivious that it's the detailed Ts&Cs and especially the warranty disclaimers that make it very difficult to "consume" (rely on) identities without a lot of extra legal scaffolding.
You're right about the role of the private sector. This all vaguely reminds me of the way data broker business models emerged in the 1990s. The likes of Dun & Bradstreet created information products that were initially based 100% on public records, and yet they charged money for simply re-configured data. The brokers added value in various ways. In the attributes provision business, I see the best value-add coming by way of a warranty of some sort, which says 'we the AP stand behind the attributes we're vouching for'. No government does that easily.
The fine print is what tends to kill federated identity (and, relatedly, the legal novelty; please see slide 4 of my 2013 Cloud Identity Summit talk here: http://lockstep.com.au/library/identity_authentication/the-idp-is-dead-cisnapa). A private sector AP which bundles attributes -- where the ultimate source of truth is government -- might do so with less fine print.
Colin Wallis
Thanks Colin.
Obviously, please correct me if I'm wrong, but with New Zealand's RealMe, my understanding is that banks use it to help verify the identity of customers when registering/enrolling them for new accounts. Once someone passes the banking registration rules, they are given a new account and credentials for logging on subsequently. That is, the banks still issue their own identities. I don't believe RealMe is used as the identity/credential for routinely logging on to a bank.
<<CW: That's right, yes. And forgive me if my hasty response in an airport lounge didn't make that clear. I was only referencing the registering/enrolling piece (or whenever those pieces of data move), which I thought was the discussion point. But noting you seem to be using 'identity/ies' in two different senses above, is adding another layer of comprehension for me..or maybe that's just the jetlag kicking in.. :-)>>.
Regarding Ts&Cs, is it the case that a bank can use RealMe, with no other data, to verify a new customer and, for instance, create a new bank account? That is, does RealMe warant a customer's identity to the extent that no other identifying details need to be checked by a bank?
<<CW: Well, to comply with AML/CFT a bank has to verify the applicant's address. Another part of RealMe, the Address Verification Service, does that with NZ Post. I don't think it is very sophisticated but seems to pass the requirement. I don't have additional knowledge on what else banks may check beyond the above, though we could speculate. As to the identity information in a RealMe ID, namely name, Dob, Pob, gender..and soon I think the FR biometric off the photo if it's recent. .. as those identity attributes in your passport, RealMe does put some limited warranty around those>>.
<<CW: sent from another airport lounge but tiredness taking over, so I'll probably just observe this thread from now on..no need to acknowledge :-)>>
j stollman
- Why do Relying Parties (RPs) require more data for digital transactions than for non-digital transactions?
- Is there a reason to separate identity from other attributes?
- Is their value in fixed Levels of Assurance (LOAs)?
_______________________________________________
WG-IDAssurance mailing list
WG-IDAs...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-idassurance
Schreiner, Susan F.
Great discussion everyone –
Steve – you make excellent points (and analogies).
In high risk transactions, my thesis is there is no net savings to an RP in relying on an externally issued generic identity, when the RP has to invest untold time and effort understanding the basis for the external identification process. It is less expensive and less risky for the RP to do its own identification and identity issuance.
I submit that a standard, perhaps a set of standards, would help at least lessen some of the work a RP would need to do and would promote interoperability. Initially (at least) these could be quite rudimentary, defining sets of identity attributes required to achieve a given level of identity assurance. NASPO has started this process by identifying sets of identity attributes that yield a level of identity resolution (across a given set of records). Given these attribute groups that NASPO identifies are all biographic at this point they do not yield high levels of identity assurance but it is an excellent start.
I agree the RP should specify the set of identity attributes it requires and that individual attributes do not have a level of assurance, but groups of identity attributes can be used to “calculate” identity assurance and I think may be used to define more finely grained levels of identity assurance than the standard four now commonly used. Of course…IMHO.
Respectfully,
Susan Schreiner
The MITRE Corporation
Thanks,
Susan
From: wg-idassura...@kantarainitiative.org [mailto:wg-idassura...@kantarainitiative.org]
On Behalf Of swi...@lockstep.com.au
Sent: Saturday, May 17, 2014 12:50 AM
To: IAWG
Subject: [WG-IDAssurance] Feasibility of high LOAs [was: IAWG Meeting notes 2014-05-15]
Thanks Andrew,
Schreiner, Susan F.
Susan, et al –
I concur that “identity” vs. “data” may not be a necessary discussion, of course at root it is ALL data.
But as systems engineers and security engineers we work to architect, build, and assure software and systems that are frequently person-centric. In this type of system, and especially within the IC and security communities, identities, and holistic views of those identities are vitally important. And interoperability across these communities is also vitally important. Hence developing some common criteria, or standards, to correlate groups of identity attributes to levels of identity assurance could be most useful.
Respectfully,
Susan
? Identity Attributes by themselves don't have levels of assurance (not a new idea), but they do have metadata (data about the attribute) that can convey:
?
o Temporal characteristics of the attribute (when an address was valid, when a name changed, etc)
o Freshness of the attribute value - (last refresh as well as what standards of refresh this attribute provider follows)
o Verification method that's been applied to this attribute value (e.g. verification against 3rd party data or an authoritative source)
? Several work efforts now or recently on this topic
?
o IDESG attributes working group
o Kantara attributes in motion working group (whose roadmap claims credit for V1.0 of the Internet2 attribute metadata registry )
o Peter Alterman's earlier work on this topic (link, anyone?)
o And thank you Susan for: Thomas, I.; Meinel, C., "An Attribute Assurance Framework to Define and Match Trust in Identity Attributes," (yours for a mere $19!)
Scott
Rainer Hoerbe
Thanks Colin.
Obviously, please correct me if I'm wrong, but with New Zealand's RealMe, my understanding is that banks use it to help verify the identity of customers when registering/enrolling them for new accounts. Once someone passes the banking registration rules, they are given a new account and credentials for logging on subsequently. That is, the banks still issue their own identities. I don't believe RealMe is used as the identity/credential for routinely logging on to a bank.
<<CW: That's right, yes. And forgive me if my hasty response in an airport lounge didn't make that clear. I was only referencing the registering/enrolling piece (or whenever those pieces of data move), which I thought was the discussion point. But noting you seem to be using 'identity/ies' in two different senses above, is adding another layer of comprehension for me..or maybe that's just the jetlag kicking in.. :-)>>.
Ken Dagg
swi...@lockstep.com.au
Thanks Rainer.
We've discussed Scandinavian federations before: https://groups.google.com/forum/#!msg/idassurance/xLz4ht6qbOI/5YdyCoLuBcoJ
BankID and the like succeed because they're legislated and are narrow in scope. Liabilities arrangements are set out in law. There is nothing to negotiate.
But my experience is that when RPs and IdPs try to negotiate liability from scratch (as they did in the unsuccessful Australian "Trust Centre" and MAMBO banking federation initiatives) they never get to a resolution. They are overwhelmed by the fine print that goes with outsourcing identification risk management to someone else, and the legal costs of reengineering long standing business practices.
Björn Sjöholm
Thanks Rainer.
We've discussed Scandinavian federations before: https://groups.google.com/forum/#!msg/idassurance/xLz4ht6qbOI/5YdyCoLuBcoJ
BankID and the like succeed because they're legislated and are narrow in scope. Liabilities arrangements are set out in law. There is nothing to negotiate.
Regards,
Björn
-- Björn Sjöholm, M.Sc. <be...@europoint.se> CISSP, CISA, CISM, CGEIT, CRISC, QSA (P2PE), PA-QSA Europoint Networking AB, www.europoint.se Phone +46 18 183030, Mobile +46 705 220110
swi...@lockstep.com.au
Sorry Björn, what I meant was that BankID is narrowly framed for personal banking and for citizen-to-government transactions.
And there is nothing at all wrong with that. I might have given the impression that "narrow" is a criticism. It is not. I have long been a fan of "closed" IDAM implementations especially "closed" PKI. Closure is a good thing -- it means legal certainty amongst other things.
I argue that the total cost of a federated IDAM system goes up dramatically when we try to "over federate", by generalising the identities too far. A single general purpose digital identity will never happen. General purpose LOA 4 identities I think too are very unlikely (without legislation) because at high levels of assurance it is simply too much work and too much cost to work out the liability fine print. At LOA 4 it will probably always be cheaper for RPs to issue their own special purpose identities ... unless there is legislation as with BankID that clarifies the Subjects' entitlements, the IdPs' liabilities and the RPs' rights.
Cheers,
Steve.
Stephen Wilson
Lockstep
http://lockstep.com.au/blog/identity
Anil John - M1EI
Yes, there was a meeting today, it was quorate.Notes here:Major discussion on the topic of Assurance Levels as related to Attributes.
andrew.Andrew Hughes CISM CISSP
Independent Consultant
In Turn Information Management Consulting
+1 250.888.9474
1249 Palmer Road,
Victoria, BC V8P 2H8
AndrewHu...@gmail.com
ca.linkedin.com/pub/andrew-hughes/a/58/682/
Identity Management | IT Governance | Information Security
Myisha Frazier-McElveen
John Bradley
<image001.jpg>
Anil John - M1EI
- Identity Establishment - Creation of a new identity record, in an authoritative source, where none has existed previously
- Identity Validation - Confirmation of the accuracy of the identity information as established by an authoritative source. Identity validation does not ensure that an individual is asserting their own identity, only that the identity is accurate and timely
- Identity Verification - Confirmation that the identity information relates to a specific individual. Verification ensures that the identity information is not being fraudulently used
- Identity Attributes - A set of attributes that uniquely describe an individual. This information needs to be validated (including associated attribute metadata) and verified to a degree that is acceptable to the RP.
- Authority Attributes - Attributes used to make access control decisions. These are authorities, licences, roles or privileges associated with a person that allow them access to physical and/or logical resources. This information needs to be validated and verified to a degree that is acceptable to the RP
- There is a process an RP will have to determine which Identity Service it will conduct business with. This process will have a set of criteria that will look at how the Identity Service conducts its business (access to authoritative sources, linkage of attribute to person process, data management practices etc.)THIS IS A DESIGN TIME DECISION BY THE RP
- There needs to be a mechanism that the RP can utilize to ensure that the information it is receiving originated at the Identity Service that it decided to do business with. THIS IS A RUN TIME EVALUATION BY THE RP
- An Identity Service that does Validation of identity information
- A "Confidence Level" you can have in that Identity Service based on design time criteria and;
- An Identity Service that does the Verification i.e. Links the validated info to a specific person (Could be the RP or could be another entity)
- The normal set of integrity, non-repudiation checks you can have on the information provided by the Identity Service to the RP
swi...@lockstep.com.au
I was wondering how long we've been talking about this.
-----Original Message-----
From: swi...@lockstep.com.au
Sent: Saturday, 17 May, 2014 3:13pm
To: "'IAWG'" <wg-idas...@kantarainitiative.org>
Subject: Re: [WG-IDAssurance] IAWG Meeting notes 2014-05-15
I don't see that finessing the difference between "identity" and "attribute" ... is helpful. Many people actually say they wish we didn't use the word "identity" in describing the engineering problem of IdM.