OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

trust-el message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: Question on perspective concerning the TC's work


fyi

-----Original Message-----
From: Dagg, Kenneth [mailto:Kenneth.Dagg@tbs-sct.gc.ca]
Sent: Wednesday, August 15, 2012 8:49 AM
To: Barbir, Abbie; 'trust-el@lists.oasis-open.org'
Subject: Question on perspective concerning the TC's work

Abbie and list administrator,

I recently tried to post the following to the Trust-Elevation TC list and was denied.  How do I get posting privledges?

Thanks,
Ken
==============================

Abbie and TC participants,

After sitting in on a couple of OASIS Trust-el TC meetings earlier this year I stopped attending because it seemed to me that how participants implicitly defined 'trust elevation' was different to my definition, and that the problem that was being solved seemed to be different than the problem that I believe we were grappling with in the Government of Canada.

It is my believe that an assertion generated from the use of a credential should be taken at its face value. That is, I believe that a LOA2 assertion (generated by use of a credential) is nothing more than a LOA2 assertion and that it cannot be elevated to become a LOA3 assertion. It is also my belief that assertions are one of the risk management controls/mechanisms that RP's can use to address their business requirements to control access to their protected resources. That is, a LOA2 assertion is one of the mechanisms that an RP can use to address a LOA2 access requirement.  It is also a mechanism, if the RP wishes to accept the risk, that an RP can use to address a LOA3 access requirement.  It is the RP's call.

During the recent Kantara F2F in Washington, though it was not on the agenda, a discussion took place around trust elevation. During this discussion it became evident that I had been operating under a slight misconception about the work of the OASIS Trust-el TC. This note is an attempt at explaining why I held my misconception as well as some points for the TC's consideration.

I now have the perception, which I would like the TC to confirm, that the work the TC is doing is not raising the LOA of a credential (e.g., raising a LOA2 credential to become a LOA3 credential) but rather identifying controls/mechanisms to mitigate the residual risk of using a LOA2 assertion provided by an IDP/CSP to meet a LOA3 business requirement of a RP. If this is indeed the case then it is an approach that the Government of Canada has been following for several years.  We call the additional mechanisms that our online services employ "mitigating factors" and would be interested in identifying additional factors that we could employ.

From the few meetings I sat in on, and the emails I have read, I did not get the impression that the output of the group was being formulated to address this issue.  It may have been my biases, but I got the impression that the TC's efforts were looking to raise the LOA of a credential that had been received by a RP/SP in order to meet the requirements of specific transactions (i.e., the requirements for most of a RP's transactions were LOA2 with the exception of a few that required LOA3). I would suggest to the TC that putting the onus on the RP, to both define their LOA requirements and to identify the controls/mechanisms it wants to use to meet those requirements, puts a different perspective on the problem space. I would suggest that from this perspective the IDP/CSP is in the clear (from a liability perspective) as long as they meet the requirements for making the LOA assertion that they are making.  The liability is with the RP who is accepting a lower LOA assertion to meet a higher LOA requirement.  In other words, it is the RP's responsibility to either use a higher LOA assertion or to put additional controls/mechanisms in place to mitigate the residual risk of using the lower LOA assertion.

Tom Smeddingoff raised an issue during the F2F discussions that an IDP/CSP might construe elevating the trust of a credential as improper use of the credential. I would suggest, as I did during the F2F, that looking at the problem space from the perspective that I am recommending addresses this issue as the LOA of the credential is not being elevated. Rather the RP is using the credential as the IDP/CSP intended and is taking the responsibility to put additional controls/mechanisms in place to address what it (the RP) considers to be a higher LOA requirement.

A recent email thread in the OASIS Trust-el TC proposed a sample analysis. I would suggest that the perspective I am proposing has only a very minor impact on the sample analysis template. I believe that the only change required is to the sub heads (i.e., from "how does a mechanism improve trust" to "how does a mechanism reduce risk"). I don't think that the descriptive text itself needs to change (I believe that it is all about risk reduction) - only the titles of that section in the template.   In addition, perhaps the TC should review any introductory/explanatory guidance before the analysis templates, to help the reader understand the 'other side of the same coin' way of looking at things that the foregoing explanation above shows.

I would suggest to the OASIS Trust-el TC that the terminology being used by the TC change from "LOA2 credential" to "LOA2 assertion" in order to contribute to the change in perspective.

I welcome comment or discussion of my way of looking at the TC's problem space.

Ken

Kenneth Dagg
Senior Project Co-ordinator | Coordonnateur de projet supérieur Security and Identity Management | Sécurité et gestion des identités Chief Information Officer Branch | Direction du dirigeant principal de l'information Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du Canada Ottawa, Canada K1A 0R5 Kenneth.Dagg@tbs-sct.gc.ca Telephone | Téléphone 613-957-7041 / Facsimile | Télécopieur 613-954-6642 / Teletypewriter | Téléimprimeur 613-957-9090 Government of Canada | Gouvernement du Canada





-----Original Message-----
From: trust-el@lists.oasis-open.org [mailto:trust-el@lists.oasis-open.org] On Behalf Of Mary Ruddy
Sent: August 9, 2012 9:50 AM
To: trust-el@lists.oasis-open.org
Subject: [trust-el] Minutes from July 26 call

Minutes for the face-to-face meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee

July 26, 2012



1. Call to Order and Welcome.



2. Roll Call

Attending (please notify me if you attended the meeting but are not on the list below)



Abbie Barbir, Bank of America

Anil Saldhana, Red Hat

Bob Sunday

Brendan Peter, CA Technologies

Carl Mattocks, Bofa

Cathy Tilton, Daon  - y

Charline Duccans, DHS

Duane DeCouteau

Colin Wallis, New Zealand Government  - y

Dale Rickards, Verizon Business - y

David Brossard, Axiomatics

Dazza Greenwood

Debbie Bucci, NIH

Deborah Steckroth, RouteOne LLC

Detlef Huehnlein, Federal Office for Information

Don Thibeau, Open Identity Exchange

Doron Cohen, SafeNet

Doron Grinstein, BiTKOO

Gershon Janssen

Ivonne Thomas, Hasso Plattner Institute

Jaap Kuipers, Amsterdam

Jeff Broburg, CA

John Bradley

John "Mike" Davis, Veteran's Affairs

John Walsh, Sypris Electronics

Jonas Hogberg

Julian Hamersley, Adv Micro Devices

Kevin Mangold, NIST - y

Lucy Lynch  ISOC

Marcus Streets, Thales e-Security

Marty Schleiff, The Boeing Company

Mary Ruddy, Identity Commons - y

Massimiliano Masi, Tiani "Spirit" GmbH - y

Nick Pope, Thales e-Security

Peter Alterman, NIST - y

Rainer Hoerbe

Rebecca Nielsen, Booz Allen Hamilton

Rich Furr, SAFE-BioPharma Assn

Ronald Perez, Advanced Micro Devices

Scott Fitch Lockeed Martin

Shaheen Abdul Jabbar, JPMorgan Chase Bank, N.A.

Shahrokh Shahidzadeh (Intel Corp)

Suzanne Gonzales-Webb, VA - y

Tony Rutkowski

Tony Nadlin

Thomas Hardjono, M.I.T.

William Barnhill, Booz Allen Hamilton



60 percent of the voting members were present at the meeting.  We did have quorum.





2. Agenda review and approval


We used the following chat room for the call: http://webconf.soaphub.org/conf/room/trust-el <http://webconf.soaphub.org/conf/room/trust-el>   chat room text is included at the end of the minutes.


There were no additions to the proposed agenda.


3. Approve Minutes

Peter made a motion to approve the minutes of June 28 and approve the correction to the minutes of July 12. Dale seconded the motion. Peter asked if there were any objections. There were no objections. The minutes were approved.



4. Overview of approach to multi-factor step-up authentication from Cathy Tilton of Daon as input to thinking about Phase 3.

Mary explained that in preparation for thinking about phase 3, we have a presentation today by
Cathy Tilton of Daon on an architectural approach to multi-factor step-up authentication.   A link to the slides can be found in the chat room.

Cathy began by asking if everyone has the presentation.

Slide 2, the purpose of the presentation is to introduce us to an approach for trust-el. The product is just an example to inform our thinking for phase 3.

Slide 3, reviews the areas of the presentation. Time permitting; there is an example at the end. The example product is IdentityX.  It is risk based multi-factor auth. It runs on smart phones and tablets.  Right now it runs on most available OS.  We have instantiated 8 different auth methods as shown.

Slide 4, It provides multi-factor auth: proof of possession of device, there is a soft cert on the device, what you know is pin/password, OTP, and multiple biometrics: face, voice and palm; and context (gps geo location.) We tried to provide a number of different traditional and non-traditional methods the RP can choose based on the risk level of the requested transaction. It can  run out of band and works for mobile apps as well.

Slide 5, shows you a few of the screens.  We will step thru the process at the end.  It is intended to be very clean.  The intent was to not require additional things to hang off the phone. It uses the inherent capabilities of the platform itself.

Slide 6, the whole idea is to have a risk aware capability. For lower risk, you can require a minimum amount of challenges to be made. As the risk level increases, you can select from your basket of auth methods to employ.  For banking, the risk may be related to dollar amount. There are also risks that are more dynamic, based on conditions such as the time the transaction occurs.

Slide 7, shows how this fits together architecturally. There are gateways to various phones (not Symbian). It is meant to be a flexible architecture so you can add auth methods in the future. It also supports less smart mobile devices via SMS, but you don't get the full set of auth methods that way.

Slide 8, the relying party would assign transaction IDs, and would map those to a specific set of policies of methods or combinations of methods, retries, and context.  This is in a plot level phase.  In the simplest form, the transaction ID may just be high, med and low. We have had other pilot customers who have 30 transaction IDs, some of which are very similar.  So it is all under the control of the RP, they chose the methods that are available. Some like biometrics.  Others stick to traditional methods they like.

Slide 9, the user makes a transaction request and then the RP makes the auth request to the auth server and based on transaction ID and user ID makes the appropriate challenge.  The user response is evaluated. This can be an immediate thing or could require an OTP. The authentication server can send a challenge to the user's phone and the user enters the response.

Slide 10, what are some of the alternatives and considerations associated with assurance levels? Will the RP request a specific set of methods or an assurance level.  That assumes that equivalence has been established.  Also does the server report pass fail or assurance level achieved?  Sometimes the RP asks for additional things. Some RP's want to know the actual biometric score. So there are different possibilities there. There is also issue of how much choice do you allow the user. What if the user has preferences? The RP can perhaps allow them to add additional factors beyond the minimum that the RP requests. When trust is elevated, you can require only the delta or required the full set of factors as if starting from scratch.

Slide11, the goal is to make it as convent as possible and as secure as possible.

Slide 12, Cathy thought we might find this interesting.  A Gartner study shows biometrics are the most preferred additional factor for online banking users.  Customer preferences do matter. Biometrics are becoming more accepted.

Slide 13, describes a couple of use cases.  The first is simple online banking. The user logs into the general website with UN/PW.  Then when they initiate a transaction, the example challenge is to provide authorization on a mobile device.  In this example, maybe just proof of possession is enough. If a subsequent transaction is for even higher value or is more fraud prone, the system may then ask the user to enter a pin and speak a pass phrase.

Slide14, shows adding the geo position. In this case, you have a location sensitive policy. For example if the request was generated in the USA, use policy A. Outside the USA, the system may request a number of different factors.  This is showing a more dynamic policy which could be based on time of day or threat level as selected by the RP.

Slide 15, lastly user choice can be a factor. Maybe a bank has set minimum requirements, but maybe the customer would be more comfortable with a higher level. Maybe the customer wants to require an additional factor for transactions over 5K.

Cathy stopped for questions.

Slide 16, begins a set of transaction step examples that describe other use cases and show screens.

Slide 17, you initiate the transaction for 15K.

Slide 18, as soon as you select transfer funds, you get a request to use the mobile devise.

Slide 19, most pilot customers are imbedding the feature in their own app. It could be preloaded as part of registration process. This example assumes registration has already occurred.

Slide 20, it brings-up the initiated transaction.  But there could be more than one transaction. The transactions could be generated from multiple service providers and queued for approval.

Slide 21, usually there is a function that checks that your phone is enrolled and your account is valid.  Once it is done, you have three choices. You can approve the item, delete it, or report it as fraud.

Slide 22, shows a PIN option.

Slide 23, shows a starting screen to take photo of your face.  Voice recognition is also supported.  We support basic versions and one that supports rudimentary liveliness.

Slide 24, is a biometric approach that uses your smart phone to take a picture of your palm.

Side 25, describes a standard voice recognition approach with liveliness option.

Slide 26, is the OTP option that would be displayed on the screen.

Slide 26, shows the completion of the transaction.

Cathy concluded by saying she wanted to introduce us to the concept of multiple factors and map them to different risk levels.

Cathy asked if there were any more questions.

Colin responded that it looks great.

Mary thanked Cathy for providing food for thought.


5. Editors update on Second Deliverable (Analysis phase)

Mary began by saying that we now have two sample analyses using the proposed analysis method.  We need to review them to see if the analysis format is complete.  Once the analysis format is complete, we can analyze the remaining methods.

Colin commented that he did add some comments too. The method seems to be working quite well.

*** Mary took an action item to re-review Colin's comments.

Colin continued that what he did was to do a cross check with some of the questions and x.1254 threats.  There were: theft and credential duplication and hijacking. I can imagine that some of these aren't relevant to all use cases, but some may be in some.  So the issue is should we include those in the chart even if in some circumstance they are not relevant.  His other thought was he saw the M 04-04 table, but it is easier to remind people of the actual LOA table rather than the risk table. So that is in the email from Tuesday from me. Apart from that I thought it was coming together. I liked the changes that were put in

Peter commented great, thanks.

Dale said when it come to the trust-el method and analysis, I see you have credential life cycle attributes. I would like to add attributes overall, not just to the credential. Some of the things we are talking about in the attribute TC at OIX, for example, are when signing-up to do geo-location; it may not be linked to the [base] credential.  It may be linked to something else you own.

Mary asked for other comments. This is very helpful.

Dale continued, for an attribute, what is the authoritative source of that attribute, rather than a secondary source? It may be the manufacturer is the authoritative source for a VIN [Vehicle Identification Number.] Need to understand if it is the authoritative source or the secondary source.

Colin said that "derivative" is another word for that besides secondary.

Mary commented that there may be multiple links in the chain of attributes, and some processes may require the source be provided.  When I was at the OASIS general meeting a few days ago, I was able to speak with Tom, and he had a positive response to the idea of enhancing Kerberos to provide the attribute source.

Mary asked if there were other comments.

Suzanne said there is concern about what would happen, she didn't know if the group has already addressed this, if you had an expired credential, so that the RP that elevated the credential, what do you do in the event that have elevated, but the credential has turned out to be bad or false. Have we addressed that? That has been discussed in other methods.

Peter responded that is more about outcomes than the method. I think I rolled it into the caveats and limits of each method, don't you think?



Suzanne replied I don't know. That is why I brought it forward.

Peter said let's talk about that issue. If I could write it up into a paragraph, that could help all to think about it.

Mary commented there could be multiple directions of feedback loops if a problem was detected.

Suzanne said I think those may have come out of a discussion of healthcare use case. A physical was given elevated access, but it turned out that his license had been expired.

Peter said let us just talk that thru. If that license was one of the required attributes, than at time of authorization that would be validated by the RP or its proxy. If it was expired, the response back would be no. So it would fail. What you brought forward is an example of why it is important to validate attributes at time of auth. Does that make sense?

Suzanne responded that may answer the question.

Mary commented that this could be a corner case of a doctor's license that was going to expire the next day and the emergency room doctor ends up working after midnight.

Suzanne responded that she was thinking that maybe an expiration of license hadn't been entered in.

Dale said she would like to put an idea forward: that this is an issue between the attribute exchange provider and the RP. Maybe the RP doesn't want to accept the thing. Or maybe it does want to assume the risk.

Mary another example is the process they have in Italy to provide emergency access to doctors so that a patient isn't killed if there is an emergency and the normal access process isn't working.

Peter remarked that we really need to encourage everyone to pick a method and give it a shot.

Mary encouraged everyone to pick a method that inspires them and send their choice to the list.

Colin said he will do this as vacation home work.

Mary asked if there were any other comments.

Colin remarked that the examples look good. He may come back with a few directed questions.


6. Attendance Update

We achieved quorum.



9. Adjournment

Mary thanked Cathy again for the information and examples of trust elevation.

Mary made a motion to adjourn.

Dale seconded the motion.

The meeting was adjourned.

>>>>>>>>>>>>>>>>>>>>

Mary Ruddy: CHAT ROOM

http://webconf.soaphub.org/conf/room/trust-el



1.  roll call

2. agenda approval

3. approve minutes

4. Overview of approach to multi-factor step-up authentication from Cathy Tilton of Daon as input to thinking about Phase 3.

 (Note we hope to get  an update from David Rennie of the UK government on applying notions of trust elevation to real world environments on August 9th.)

5. editor discussion on Second Deliverable (Analysis phase)

6. conclude
Mary Ruddy: Link for today's presentation: https://www.oasis-open.org/apps/org/workgroup/trust-el/document.php?document_id=46549
anonymous morphed into Suzanne Gonzales-Webb







----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]