[WG-IDAssurance] IAWG Meeting notes 2014-05-15

1 view
Skip to first unread message

Andrew Hughes

unread,
May 15, 2014, 1:08:45 PM5/15/14
to IAWG
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 

Schreiner, Susan F.

unread,
May 15, 2014, 1:33:48 PM5/15/14
to Andrew Hughes, IAWG

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

unread,
May 15, 2014, 1:36:37 PM5/15/14
to Andrew Hughes, IAWG
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?)
    • 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!)
What am I forgetting?
--
Scott


_______________________________________________
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.

unread,
May 15, 2014, 1:47:01 PM5/15/14
to Scott Shorter, Andrew Hughes, IAWG

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

AL Policy Document v1.0.doc

Richard G. WILSHER (Zygma CEO)

unread,
May 15, 2014, 2:14:52 PM5/15/14
to IAWG

It seems to me we’re getting distracted over what an attribute is.  I thought that we’d previously determined / discussed / agreed that, when we talk about ‘attributes’, we are not concerned with ‘attributes’ which relate to elements of an individual’s identity, which one might call ‘identity attributes’, but with attributes of an individual which can be trusted because they are assigned based upon a proven and authenticated identity.

That is not to say that a discussion of ‘identity attributes’ is not worthwhile, but it should fall within the scope of the IAF/IAWG if that’s what it is to be.  A discussion about ‘characteristic attributes' (for want of a better distinguishing term, hereafter ‘CharAtts’, to be pronounced like ‘carats’ ;-) is an equally valid discussion but one which might want to be within a separate WG, although there is a clear relationship to authenticatable identities.  Such CharAtts might be:  membership of a club or professional institution, membership of the military, a qualification achieved or granted, …  each of those would be related to a proven (i.e. the authenticatable bit) identity, that identity having been determined by an IPV process such as many Kantara-Approved CSPs provide.  Such a discussion should address, inter alia, the requirements for the IPV processes related to those who issue Attributes, who must themselves be authenticated (e.g. RGW shows up and present to an RP a qualification XYZ:  the RP needs to ensure that they can authenticate the organisation Alpha-Beta as being a legitimate issuer of the class of Attributes XYZ in order to then trust that asserted characteristic of the stated individual (no authentication of the individual need be performed by the RP to trust the CharAtt because they have authenticated Alpha-Beta, which gives confidence that that entity authenticated the holder of the CharAtt prior to issuing the CharAtt in association with the identity RGW.  The RP may of course have other reasons for wanting to authenticate RGW, who wouldn’t??!

 

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
cid:image001.jpg@01CEC9E9.E9D38700
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
    • Peter Alterman's earlier work on this topic (link, anyone?)

Scott

image001.jpg

Richard G. WILSHER (Zygma CEO)

unread,
May 15, 2014, 2:15:16 PM5/15/14
to IAWG
image001.jpg

Schreiner, Susan F.

unread,
May 15, 2014, 2:25:09 PM5/15/14
to Scott Shorter, Andrew Hughes, IAWG

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

unread,
May 15, 2014, 10:48:13 PM5/15/14
to Richard G. WILSHER (Zygma CEO), IAWG
Interestingly, I seem to have sparked a Twitter identerati dust-up on
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

unread,
May 15, 2014, 11:33:41 PM5/15/14
to IAWG

 

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

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.

Andrew Hughes

unread,
May 15, 2014, 11:59:56 PM5/15/14
to swi...@lockstep.com.au, IAWG
I'm starting to think of the Assurance of Attributes in this way (which is probably flawed):

The RP determines which attributes and their qualities are needed to fulfill the RP's business need. They describe this requirement in terms of "levels of assurance" as defined in the trust framework to which they subscribe. The attribute providers frame up their offerings in those same terms to be able to negotiate the contract. In this perspective, attribute assurance is a vehicle for increased efficiency in contract negotiation. 

Fire away!
Andrew. 


--

Andrew Hughes CISM CISSP 
Independent Consultant
In Turn Information Management Consulting


1249 Palmer Road,
Victoria, BC V8P 2H8

Rainer Hoerbe

unread,
May 16, 2014, 2:27:40 AM5/16/14
to Wilson Stephen, IAWG
While I agree that risk needs to be assessed per relying party, this does not prevent the classification of controls into levels of assurance. In fact, larger cross-organizations networks have to federate to deal with complexity, as pair-wise risk assessment is not feasible. I do not believe in a universal set of LoAs, but as a system for a sector or several sectors it has proven useful.

Cheers, Rainer

Patrick Curry

unread,
May 16, 2014, 2:53:41 AM5/16/14
to Rainer Hörbe, IAWG
I agree there’s no one size fits all.  However, the current free for all in the market is proving to be highly limiting and costly. In UK, some of the leading companies have been discussing how this fragmentation is causing great difficulties in SMEs and government organisations trying to get re-use, security and affordability by moving to cloud for the purposes of collaboration and compliance.  The US cybersecurity framework and other national and EU regulations are pushing towards the LoAs as a "baseline for negotiation", i.e. a minimum set for each LoA.  The side effect is that BBFA and MACCSA are seeing small groups adding controls that exclude others at a given LoA.  Memories of Medium Hardware etc now becoming LoA 3+ or LoA Variant Z etc.

I guess we will be back to the typical matrix of national views vs international industry sectors, requiring a compromise or float high, when you want to relate two or more cells in the matrix.  There’s no escaping the complexity!

Things are moving quickly.  It will be interesting to see what happens

regards,

Patrick

Patrick Curry
Director
Clarion Identity Ltd

M:   +44 786 024 9074
T:   +44 1980 620606
patric...@clarionidentity.com



Natale, Bob

unread,
May 16, 2014, 4:03:32 AM5/16/14
to Andrew Hughes, IAWG

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

unread,
May 16, 2014, 8:36:57 AM5/16/14
to Robin Wilton, IAWG
+1 I whole heartedly agree with you. 

Ken Dagg

unread,
May 16, 2014, 8:39:29 AM5/16/14
to Natale, Bob, IAWG
I offer the following to throw my two cents worth (even though Canada no longer has the cent) into this discussion and to clarify what I have been saying in a set of disconnected but related conversations over the past couple of weeks. I should also, as a disclaimer, say that, having recently retired, I am no longer an employee of the Government of Canada.

In my opinion, to ground it, the discussion that is taking place needs to be looked at from the perspective of the Relying Party/end Service Provider (RP/SP). I believe that RPs/SPs (be they in the public or private sector) have two basic requirements: 1) to enrol a subject (person, machine, or organization) for the service they provide and 2) determine the level of service that the subject is entitled to receive. I'll refer to the first as "enrolment" and the second as "entitlement".

To do either task (whether in the manual or internet environment) the RP/SP identifies the set of attributes it requires from a subject to minimize the risk that they (the RP/SP) do not get it right (i. e., they deliver the wrong amount of service to the wrong subject). In some cases this is a very simple model: to have someone purchase groceries a grocery store does not really care who the person is (enrolment) only that the person can pay for the groceries (entitlement). In other cases, welfare payments, the model is much more complex. Regardless, for both tasks the RP/SP needs to ensure that the attributes are good and that the attributes are linked to the subject. 

In my opinion, a good attribute is an attribute that has been verified by some mechanism. For example, date of birth can be verified to be a valid date, a telephone number can be verified by a Telco to be be a good telephone number, a credit card number can be verified by the issuer to be a good number. This verification is done with no knowledge of whether or not the attributes are linked to the subject. In some cases a RP/SP may identify that it requires some characteristics associated with the verification (i.e., a credit card has not been cancelled). To me this is, though possibly somewhat technically challenging, a solvable problem. For example, one of the challenges could be real time checking that a telephone number is active. On the other hand, the capability exists today to verify that a credit card number is active.

To me the more challenging activity, for either enrolment or entitlement, is checking or validating the linkage of an attribute, or bundle or attributes, to a subject. In the manual world, where in-person enrolment and determination of entitlement requires an in-person visit, RPs/SPs have evolved elaborate processes to mitigate this risk. When required, they have also instituted processes to ensure ongoing entitlement requirements are met. However, in my opinion, these processes are being "stretched" today with the easy access to "fake" documentation that seems to exist ("souvenir driver's licences") and with the wide availability of world-wide communications networks. To their dismay I also believe that RPs/SPs are finding that their existing processes are not really working or relevant to the digital world.

My former employer, the Government of Canada (GC), over an extended period of time, consulted multiple GC RPs/SPs to identify their requirements with respect to enrolment - specifically how could they be assured of the identity of the person they were enrolling. The result of this work was published in February 2913 as the Standard on Identity and Credential Assurance (http://www.tbs-sct.gc.ca/pol/doc-eng.aspx?id=26776&section=text). It identifies what a GC RP/SP must do to meet the LOA requirements they have previously identified for their specific service offering. Please note, though I believe for this discussion the difference is not relevant, that the GC defines credential differently than the US government.

The issue of determining the specific attributes each RP/SP requires to undertake this identity assurance task is left to the RP/SP as is the task of identifying the attributes they require to determine entitlement (either initial or ongoing) and how they verify the attributes are good and linked to the subject.

In my opinion, the challenge that needs to be solved is how a RP/SP, after they have determined their enrolment and entitlement LOA requirements, can trust an assertion that IdP/AP (or whatever service provider we want to call it) makes that an attribute or bundle of attributes is linked (belongs to) a subject.

Ken

Faut, Nathan E

unread,
May 16, 2014, 2:27:02 PM5/16/14
to Natale, Bob, Andrew Hughes, IAWG

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

unread,
May 17, 2014, 12:50:12 AM5/17/14
to IAWG

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

unread,
May 17, 2014, 1:13:49 AM5/17/14
to IAWG

 

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

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.

 

 

 

Colin Wallis

unread,
May 17, 2014, 2:49:50 AM5/17/14
to IAWG
<<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.>>

Hmm..well it depends.. In NZ we seem to have no problem with RP govt agencies and bnks accepting RealMe identity pulled off the back of the passports database, with some but limited liabilty..


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

unread,
May 17, 2014, 10:35:56 AM5/17/14
to swi...@lockstep.com.au, IAWG

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 Logo

_______________________

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

unread,
May 17, 2014, 11:33:48 AM5/17/14
to Smedinghoff, Tom, swi...@lockstep.com.au, IAWG
I'm also jumping in to give a view from the front line and also without perhaps understanding the root of the discussion.

The first type of RP wants simple data values – so its a simple yes this person is over 18 and is in this location, or whatever, and identity as such doesn't come into it (the rest of the process involves logging in, but really that can't be called identity as such, although you are sort of identifying yourself by use of credentials). However, the data can be requested both at login and post login – not sure if this is relevant to the argument though.

The other type of RP we come across want 'identity assurance', I.e. An identity which is set to an assurance level such as 1, 2, etc. This assurance comes from validating them using details about their residence, out of wallet questions and so on. You could argue of course, this is simply again, just sharing data, the data in this case having a flag that says this person is verified and assured to level X. But then we get into the philosophy of exactly what is an identity and how can we mirror real world ID's in a virtual world.

The process of an individual asking for access or similar from a RP is, if you break it down into a reductionist argument, is just about sharing data.  

But…my concern with dropping the word identity altogether and becoming highly reductionist, is that when we come to design these systems and the people using them decide what requirements are needed within the system, then we may end up being less holistic about that design and missing important criteria such as privacy and the ability for individuals to control these data and so on.

I don't think the argument needs to be made, is this identity or just data, I think the two are intrinsically linked and it would be a mistake to separate the two entirely, yes, recognise the fundamental and reductionist viewpoint, but keep a holistic eye on the system and its design.

Susan

Susan Morrow
Head of R&D
Avoco Secure Ltd
@avocoidentity

E.  susan.morrow@avocosecure.com 

Avoco are providers of Cloud Identity, Security and Privacy solutions.

Registered Office: Avoco Secure Ltd., 16 St. Martin's-le-Grand, London EC1A 4EE. Company number : 04778206 - Registered in England and Wales.

This email including any attachments is confidential and may be legally privileged. This email is  intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient, be advised that you have received this email in error, please advise the sender IMMEDIATELY by return email and then DELETE it from your system. The unauthorised use, distribution, dissemination, copying or alteration of this email is strictly FORBIDDEN.

Andrew Hughes

unread,
May 17, 2014, 11:35:20 AM5/17/14
to Smedinghoff, Tom, IAWG
Spot on, both of you.
From time to time I work on conceptual models that consider the domain as a special-case information management, information assurance, and information exchange domain. While not always a perfect fit, the ways one has to think of it in this way allows for some interesting insights.

Especially useful is the information flow / data flow diagram. It shows the actors, interfaces, and data flows - and helpfully, it is an important analysis tool for privacy analysts. I find it useful when considering how information crosses security/trust boundaries and when thinking about how to handle the provenance issue.

Andrew. 

Edwards Wildman Logo

_______________________

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

unread,
May 17, 2014, 2:53:03 PM5/17/14
to Andrew Hughes, Smedinghoff, Tom, IAWG
Talking with Eve about this, she commented, nice and succinctly, "I would say "data" is maybe fine at the technical level...but at the regulatory and human-rights level, it's important to qualify it with "personal". Then the philosophical argument over identity can at least acknowledge that unique identifiers, packages of attributes, etc. are just species of personal data."

Susan

j stollman

unread,
May 17, 2014, 6:40:45 PM5/17/14
to Susan Morrow, IAWG
I fear that my thinking runs a bit afoul of the gathering consensus of the last several notes that share the thesis that Tom summarized well:

(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?.

I do not dispute that this is a succinct statement of the "goals" of an RP.  But as simple as this summary of an RP's goal may be, there are real-world reasons that an RP would want to collect additional information -- exclusive of a possible desire to capture data for marketing purposes or resale.  

In a world where everything goes right, all we need to collect is the data to answer the three questions.  But things often go wrong.  Imagine that an RP sells a widget to a Subject.  According to the model above, the RP needs only the provision of payment information (e.g., a credit card number) and a shipping address.  He doesn't need to know the name of the buyer or anything else about him when the Subject is an upstanding citizen.  But what happens if the Subject provides a stolen credit card number and the theft is discovered only after the widget has been shipped and received.  Having collected only the credit card and address, the RP has no ability to pursue the thief.  Accordingly, in conducting the transaction, his risk manager might suggest that the RP also collect some additional information about the Subject sufficient to try to track him/her down to recover the widget and/or damages from the bad transaction.

The point here is that we have a tendency to look at interactions assuming that everything will go as planned.  If we take the perspective of considering all of the things that could go wrong, we come up with a different answer.  And each "bad" scenario typically drives the need for collecting additional data.

Am I missing something that this problem seems more complex to me?

Jeff 

--
Jeff Stollman
stoll...@gmail.com
1 202.683.8699

Truth never triumphs — its opponents just die out.
Science advances one funeral at a time.
                                    Max Planck

Ken Dagg

unread,
May 17, 2014, 7:19:48 PM5/17/14
to j stollman, IAWG
Jeff,

While I agree with what you say in principle I have to ask the question - what does the RP do today in the non digital world.

If they are willing to live with the consequences in the non digital world why aren't they willing to live with it in the digital world. While it would be nice to be "better" i do not believe that this should be the goal of digital transactions.

Use of a bad credit card is the same in both environments ... it is fraud. As such, it needs to be dealt with in the same way.

Ken
--

swi...@lockstep.com.au

unread,
May 17, 2014, 8:30:45 PM5/17/14
to IAWG

 

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

unread,
May 17, 2014, 8:49:57 PM5/17/14
to IAWG

 

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

unread,
May 17, 2014, 9:51:35 PM5/17/14
to swi...@lockstep.com.au, IAWG
I fully agree that the main 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".

To that end, the Government of Canada Guideline on Defining Authentication Requirements and the Standard on Identity and Credential Assurance, identified how RPs determine the LOA they need in that data and what they need to do to satisfy that LOA. Philosophically this is an easy problem to solve.

However, in my opinion, authoritative sources (most of whom I believe are public sector organizations) are not technically or policy enabled to satisfy the needs of RPs. Private sector organizations could be a proxy for these authoritative sources. However, this role has not been examined from the perspective of how it meets the need to "improve the reliability and availability of the data that RPs need to know about Subjects, and to enhance the pedigree of that data". While several public sector organizations advertise that they provide this service I'm not convinced that RPs are buying into what they are selling.

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.

Ken

swi...@lockstep.com.au

unread,
May 17, 2014, 10:31:54 PM5/17/14
to IAWG

 

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

unread,
May 17, 2014, 11:43:17 PM5/17/14
to Stephen Wilson, IAWG

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

unread,
May 18, 2014, 4:07:08 AM5/18/14
to Stephen Wilson, IAWG
I will briefly address three points raised by Steve and Ken:
  1. Why do Relying Parties (RPs) require more data for digital transactions than for non-digital transactions?
  2. Is there a reason to separate identity from other attributes?
  3. Is their value in fixed Levels of Assurance (LOAs)?

Why do Relying Parties (RPs) require more data for digital transactions than for non-digital transactions?
I think the current reason that RPs seek more data for digital transactions is that they value this data for other purposes and can get away with requiring it because of the asymmetry of power in the current market.

That said, I think that the risks are larger in the digital world where fraud can be perpetrated on a larger scale.  A fraudster can replicate his fraud to hundreds of RPs with a few keystrokes -- much easier than going from bricks-and-mortar store to store.

Is there a reason to separate identity from other attributes?
I am inclined to agree with Steve that the distinction between identity attributes and other attributes about an entity may often prove to be artificial.  But I think that there is a difference between a entity's ipseity (fundamental, uniqueness) and the various attributes we use to approximate ipseity.  If we used DNA to establish the absolute uniqueness of a person, we would establish an identity in the mathematical sense of having a 1:1 relationship between DNA and the ipseity of the person, i.e., DNAx≡PERSONx.  But we typically use other attributes about PERSONx to infer his/her ipseity.  In such a case, while some attributes may be stronger than others in establishing the unique ipseity of a person, I don't know that there is a clear cut-off that makes some attributes worthy of being called "identity" attributes.

Is their value in fixed Levels of Assurance (LOAs)?
This question is really less a yes/no question than one of degree.  

The complexity of building a trust framework with the granularity to support risk management decisions that vary from transaction to transaction based on the parties involved, the nature of the transaction, and the completeness of the data available about the parties and the transaction is high.  Especially in these early days of trying to build this trust framework infrastructure, this complexity may be more than we can expect to achieve.  The issue becomes what simplifications can we make that will still provide enough value that it will be successful in the market.  We don't need a complete solution; we need only something that works for enough parties (Subjects, RPs, Identity/Attribute Providers), to get some traction.

While we have yet to gain much traction (as evidenced by the limited number of RPs willing to participate, it may be that it is the fault of the simplification we have chosen by going to a step-wise approximation of the continuous risk-management decision that is what happens in the "real world."  I am not a fan of the 4-tier LOA simplification.  I would prefer that we enrich (and complicate) the provision of attributes to more thoroughly articulate their provenance.   This would allow participants to make their own individual assessments of risk, without the artificial construct of four pre-defined LOAs.  But I am not yet willing to concede that the shortcomings of the LOA model are the reason for our current "failure to launch" a viable, trust framework.

Jeff






_______________________________________________
WG-IDAssurance mailing list
WG-IDAs...@kantarainitiative.org
http://kantarainitiative.org/mailman/listinfo/wg-idassurance

Schreiner, Susan F.

unread,
May 18, 2014, 7:47:16 AM5/18/14
to swi...@lockstep.com.au, IAWG

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.

unread,
May 18, 2014, 8:00:33 AM5/18/14
to Susan Morrow, Smedinghoff, Tom, swi...@lockstep.com.au, IAWG

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

unread,
May 18, 2014, 9:16:16 AM5/18/14
to Wallis Colin, IAWG

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


Stephen,

There are other countries that have federations crossing sectors, like those in the scandinavian countries. Their BankIDs have been used to authentication to Internet banking, government services and other sectors as well.

Other European countries have established legislation (e.g. Austria) or are in the process to enable remote account opening using electronic credentials, although this has not picked up in volume yet.

The opposite case has happened as well. I know from several countries where banks and telcos were not willing to provide identities for various reasons. 

- Rainer

Ken Dagg

unread,
May 18, 2014, 9:59:28 AM5/18/14
to Schreiner, Susan F., IAWG
The points that have been made are very true.  The risk mitigation process that a RP follows must be determined by the RP after it determines what assurance they require. While they should, in my opinion, subscribe to the 4 levels that have been defined and are in wide use this is not a precondition to their determining what they need. The 4 levels are only convenient ways to categorize assurance requirements so that suppliers know what they have to do to meet an RP's requirements.

The risk mitigation process, regardless of the the RP's required level of assurance, could include as one of its components the assurance of identity or of attributes provided by an identity / attribute provider. That is to say, the RP does not have to rely on the assurances they are provided by one external service provider. They could go to several suppliers or even do checks themselves before granting access.

Ken

swi...@lockstep.com.au

unread,
May 18, 2014, 2:25:04 PM5/18/14
to IAWG

 

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

unread,
May 18, 2014, 2:28:56 PM5/18/14
to wg-idas...@kantarainitiative.org
Hi Steve


swi...@lockstep.com.au skrev 2014-05-18 20:25:

 

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.


That is a very simplified statement. The solutions are authentication only, so in that way they are narrow in scope, but they are not narrow in regards to market. The liabilities are not set out in law for all usages.

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

unread,
May 18, 2014, 3:07:29 PM5/18/14
to wg-idas...@kantarainitiative.org

 

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

unread,
May 19, 2014, 11:13:13 AM5/19/14
to Andrew Hughes, IAWG
>Adam is under the impression that FICAM is waiting for 
>feedback from Kantara on the Attributes question

Yes, and our "Attributes question" is very narrowly scoped. The question came about since we got feedback from FICAM TFSA Approved Identity Services that "Attribute Refresh Intervals" are something that has cost implications that need to be balanced with other factors. 

To that end, Kantara volunteered to lead a community discussion that would result in a set of recommendations to FICAM TFS on this topic.

Regards,

- Anil

:- 
:- Anil John [GSA]
:- http://info.idmanagement.gov/
:- 202.810.5091
:- 
:- Response Time - 24 Hours


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:

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

unread,
May 19, 2014, 11:50:12 AM5/19/14
to swi...@lockstep.com.au, IAWG
+1 +1 +1 +1 +1
 
I obviously whole heartedly agree :-).  I've said for some time that the only difference between what I call "Standard identity attributes" and other attributes is that we've cracked the code in how to develop criteria around their verification to establish the Levels of Assurance.  However, when it comes down to it, the basic premise that needs to be solved is what does an RP need to know about an End User to be able to transact with them. THAT is their identity.  Not some list of attributes that intellectually speaking in our ivory towers we've determined is sufficient information to uniquely identify an individual.  If it is of no benefit to the RP then have we really uniquely identified the individual?  We've intellectually broken apart authentication and authorization for years to make the problem easier to solve except that it hasn't really solved the problem for the relying party. 

John Bradley

unread,
May 19, 2014, 12:02:50 PM5/19/14
to Myisha Frazier-McElveen, IAWG
I think there are differences in the nature of the attributes though they may seem to be the same.

In the case of address. 

The SP validates the persons address at the time of registration to disambiguate that person at that point in time.   This allows for recovery in that even if the person moves proving where they used to live can be used to disambiguate the correct subject from someone with the same name who never lived at that location.

While the schema may be the same is the SP/RP asking where the person lived at the time of registration or where the person is living today so there identity can be resolved in other directories?

To my mind SP800-63 is requiring the IdP to know the first type of attribute for making a consistent assertion that the subject using the credential is the same as last time and the account is protected from hijacking. 

In the second case the RP/SP wants close to real time attribute validation for identity resolution.

I think the underlying question is if 2 is a value add of 1 or required for 1,  and how much will it cost to get to 2.

I personally think the two uses of attributes should be separate.  Strong credentials resistant to account takeover have value and should be able to be used without releasing any PII.

Just my 2 cents

John B.

<image001.jpg>

Anil John - M1EI

unread,
May 19, 2014, 12:21:52 PM5/19/14
to John Bradley, IAWG
>Strong credentials resistant to account takeover have value 
>and should be able to be used without releasing any PII.

+1

The approaches in NZ, Canada and US FICAM TFS Component services support this exact model. 

Having the ability to assert "I am the same person that showed up at your front door", without needing to assert "I am Anil John" has a lot of value.

re: Attribute Assurance

This a wide-ranging discussion. Some common context and terminology may be helpful in level setting.
  • 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

At the end of the day, we are indeed trying to answer the question "What information does the RP need in order conduct business transaction X with Subject Y"

And that could be:

  1. 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.
  2. 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
I would make a case that in the near term world:
  • 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
My personal viewpoint is that there is no "Attribute Assurance". Instead there is:
  1. An Identity Service that does Validation of identity information
  2. A "Confidence Level" you can have in that Identity Service based on design time criteria and;
  3. 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)
  4. The normal set of integrity, non-repudiation checks you can have on the information provided by the Identity Service to the RP
... that will feed into the RP decision "I allow Subject Y to Conduct transaction X"

Regards,

- Anil



:- 
:- Anil John [GSA]
:- http://info.idmanagement.gov/
:- 202.810.5091
:- 
:- Response Time - 24 Hours


swi...@lockstep.com.au

unread,
Aug 8, 2021, 3:41:59 PMAug 8
to IAWG

 

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.

Reply all
Reply to author
Forward
0 new messages