RE: Minutes for March 8 Trust-el call

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

8 March, 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 - y

Anil Saldhana, Red Hat

Bob Sunday - y

Brendan Peter, CA Technologies - y

Carl Mattocks, Bofa

Cathy Tilton, Daon

Charline Duccans, DHS

Duane DeCouteau

Colin Wallis, New Zealand Government

Dale Rickards, Verizon Business - y

David Brossard, Axiomatics

Dazza Greenwood

Debbie Bucci, NIH - y

Deborah Steckroth, RouteOne LLC

Detlef Huehnlein, Federal Office for Information

Don Thibeau, Open Identity Exchange

Doron Cohen, SafeNet

Doron Grinstein, BiTKOO

Ed Coyne, Dept Veterans Affairs - y

Gershon Janssenll – y

Ivonne Thomas, Hasso Plattner Institute

Jaap Kuipers, Amsterdam

Jeff Broburg, CA

John Bradley

John "Mike" Davis, Veteran's Affairs - y

John Walsh, Sypris Electronics

Julian Hamersley, Adv Micro Devices

Ken Dagg, Canadian Government - y

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

Rebecca Nielsen, Booz Allen Hamiltony

Rich Furr, SAFE-BioPharma Assn

Ronald Perez, Advanced Micro Devices

Scott Fitch Lockeed Martin

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

Shahrokh Shahidzadeh (Intel Corp) - y

Tony Rutkowski

Thomas Hardjono, M.I.T. - y

William Barnhill, Booz Allen Hamilton

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

Abbie noted that Chrome was quickly hacked when a reward was offered.

2. Agenda review and approval

We used the following chat room for the call: 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 agenda and we proceeded with the agenda.

3. Approve Minutes

Abbie made a motion to approve the minutes for February 9, and to append the notes from the February 23 call to these minutes (since we did not achieve quorum on February 23.)

Brendan seconded the motion.

There were no objections. The motion passed

4. Presentation by Shahrokh Shahidzadeh, Intel on endpoint uses cases. Slides are to be submitted to the TC

Abbie said the slides have been sent to the list.

Shahrokh said the purpose of this presentation is to stimulate discussion. He needed to remove some slides about products that were not yet announced. Some ideas are under development. He wants to talk about something that is fundamental to advancing the trust of the platform. The simplistic question is: how do you guarantee that the devise will provide multi-factor auth. There is a little more to it, how do we secure the connection to cloud and to peer devices, this is even more important as we go forward. The question is who is watching the cloud. If I want to use my device as a radio, can I trust that no one is listening to it?

Slide 3, is the traditional problem of a platform talking to the cloud and a peer platform. In this scenario you have userID and password for traditional login to a particular private cloud. Then the cloud needs to further investigate and authenticate the device. Then the cloud can verify the identity of the device. Ultimately all the communication is encrypted.

Slide 4, the key ingredient is a hardware vault that is immutable and tamper proof. Device auth is a major building block. As we move forward over the next couple years, we will have extensive hardening of device identity. It is important to understand this is not a one-time thing. The device needs to be provisionable throughout the life of the platform across multiple owners. You need to be able to re-provision the device. There has been a significant amount of random number generation. One for the key things is having an integrated and isolated entropy. One of the things we do in our hardware is provide that source of entropy. That is one of the key ingredients in connecting to the cloud and services. In the next few weeks, you will see an announcement about that. Once you have device identity, you need to marry that to yourself via some biometric. We are looking at a number of methods, some are expensive. We are looking for approaches that can scale and with expense that can be mapped overall all your life’s uses (car, bank, etc.) Like a driver’s license type of device with some integrated electronics, which is a little more advanced than what is available today. We are looking at iris scan integration into the devices. If you already have a phone, you don’t need an additional card. With all of that, there is significant need for client and cloud APIs so you can take advantage of this and identify the endpoint device, by having secure and reliable API’s. We do have some tokenization projects that are public.

Shahrokh paused to allow questions.

Shaheen asked if the device can be used with multiple users. How does the registration take place?

Slide 5, Shahrokh said that was a great lead-in. There is an integrated SIM card that is policy based. Multiple users are provisionable. In that case, the biometric of the person and the identity of the device need to be unique. Different life stages of the product are inclusive of multiple users. The issue with multi-user is how do you separate the DIMS. Is the hard disk (or any data address), left by the previous user, able to be accessed? This depends on how we do the encryption. The idea is that if I log in, I have a dedicated region of memory on the hard drive. If a new user logs in, the DIMS goes to a state where the new user can’t access the old memory. Of course hardware attacks are possible, so the data is also encrypted.

The relationship of cloud and machine is established by registration. That machine has some information about user login and password, so it isn’t just the identity of the device. It is a combo of the identity of the user and the device. The device identity by itself doesn’t provide anything.

The advantage of Intel providing an integrated SIM solution in the next few years is we would be operator agnostic. The user will be able to claim a region inside the vault with their own lock.

….. Firmware will be verified at boot time to ensure that the hardware itself has not been hacked. The biggest problem with SIM cards is they are easily removable. There is the possibility of someone removing information from your SIM card, but if it is integrated into the hardware and if you guarantee the vaults are segregated, then the only issue is refurbishment when ownership is transferred. There is a way to erase and reset the conditions.

Abbie noted that Thomas has a question about how this relates to TPM.

Shahrokh said we don’t have today any claim on replacing TPM or to be classified as TPG compliant. The difference is TPM is a discrete component outside the platform .Our concern is at a different level. If your BIOS is dead or under attack, then the TPM won’t have a chance to wake-up. Then the problem is much more complicated.

Shahrokh said one of the key things he wanted to cover is biometrics. Intel is looking at a number of solutions with other components such as smartcards, fingerprints and iris scans. We are working to combine trust elevation of the platform with biometrics.

Shahrokh said we are serious about this and have spent a lot of money on acquisitions, including the McAfee acquisition, so we can have hardware and software security across the board.

Abbie commented about the news that chrome was hacked in 5 minutes or less. Abbie joked that he lost his bet of 2 minutes. The point is it shows you that company culture makes a big different on how secure your products are.

Abbie said what he wants us to get from today’s talk is you can’t rely on your browser. You need to have confidence in your endpoint. He asked Shahrokh if he submitted a use case. We need this in writing.

Shahrokh said his main concern is that he had to strip of the details from this presentation today for legal purposes. He will bring full user case to the F2F.

Abbie asked of there were any more questions.

Abbie thanked Shahrokh very much. He noted that we had less than 20 minutes left, and said he would like each one of us to send him an agenda item for the F2F. Our objective is to have our first deliverable out the door about two weeks after the F2F. He wants to make sure we have done our homework and look at the structure of the first deliverable. The first deliverable is just a base. The sooner we get it out, the sooner we can focus on the real work we have to do, So want to spend time setting the stage for discussion of the protocol issues.

Abbie opened the topic up for discussion. How can we use the first day on the first deliverable and the second day to set the stage for the 2^nd deliverable? We need to look into how to develop a protocol for elevating trust, what is in and out of scope for that discussion and who is missing from the table.

Peter commented that the questions Abbie just asked are very important. My first thought is our first deliverable is what we can get. We never thought we could get everything. We need to accept that we got as much as we could get. Again, I would say, the defining line on what is in and out is what falls outside the charter and what falls inside the charter. That should be a voting thing. Editors make a list and the group votes on leave in or out. For the second deliverable, we need to do the analytic work on the methods and techniques. Questions on what we missed, while important, are left over from the first deliverable, He thinks we should focus on doing our analytic work on what we found.

Abbie asked how familiar the group was with the open auth work? There is a group of 20 or 30 companies. I think we need to take these as inputs for our 2^nd and 3^rd deliverable. Our group has to be very open.

Abbie send an email to the list with a link http://www.openauthentication.org/

There was a discussion of Open Auth vs. OAuth. Open Auth is more of an architecture for strong auth. OAuth 2.0 is lighter weight.

Abbie said we need to discuss this in the second half of the F2F. He wants participants to come prepared. Look internally in your organizations and see if has been used and what has been learned. He would like to set the stage for being successful in the 2^nd and 3^rd stages.

Abbie commented that there is the question of how you signal trust elevation. How do you ask for elevated trust?

A comment was made that this is an OTP based solution.

Peter said what we need to do is consider what parts are credential based and what parts aren’t. The financial services industry has taken this as part of its heart beat, we need to take it seriously. It would like to suggested to elevate this to one of the focal points. I want to figure out where it fits in the spectrum.

Abbie said in the second part of the meeting we can discuss what is in and out of scope for the 2^nd and 3^rd deliverable. If the open auth doesn’t suit our purposes, we can look at it and move on. In the second half day, we can discuss the boundary for where we can work. Abbie would like people to come opinionated.

Abbie suggested that maybe we could also get a NSTIC person to give an overview.

Peter took an action item to make a formal request for Jeremy Grant to stop by the F2F.

Mike Commented that OMB released a policy statement in October. It has to do with policies on types of credentials acceptable to the federal government. He wants to ensure we do something that is acceptable to the FICAM.

Abbie said that is an extremely good point.

Peter said we can create a cross of trust elevation and transaction trust techniques and the federal model. He talked with Jeremy earlier this week, and told him we will have to move the government to accepting a non credential-based approach and Jeremy responded that he knows.

5. F2F meeting details update.

• Day 1: Wednesday, 14 March 2012, 01:00pm to 05:00pm ET

· NIST, Gaithersburg, MD, Lecture Room D.

· CHAT ROOM

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

· Many thanks to Bank of America to sponsor the call (It is the same bridge as the bi-weekly calls)

· Passcode: 637 218 8139

· Toll Free: 1866 222 6652

· Int'l Toll: 1-980-939-6928

• Day 2: Thursday, 15 March 2012, 09:00am to 05:00pm ET

· CA’s Washington DC office. 1401 I Street, NW, Suite 1220.

· CA shares their suite with a company named Travelport, and CA’s name is not on the Suite.

· Visitors can ring the bell and the front desk assistant will let them in.

· If folks are taking the Metro, the McPherson Sq. Station is directly across from our office.

· We do not have visitor wireless access here in this office, so if folks need connectivity,

· they’ll need to bring a laptop card or have a Mifi. (Mary will bring a Mifi.)

· CHAT ROOM

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

· Many thanks to Bank of America to sponsor the call (it is the same Bridge as the bi-weekly calls)

· Passcode: 637 218 8139

· Toll Free: 1866 222 6652

· Int'l Toll: 1-980-939-6928

Brendan wanted to clarify that this is not an official CA corporate office, so we don’t have CA’s standard guest wireless access. So people will need to bring their own Mifi or laptop device. He will bring in food for breakfast and lunch.

6. Mary and Editors to provide an overview of Committee Draft of first deliverable

She received detailed feedback from two of the editors on the last version. Some of the feedback was to further abstract and collapse some of the examples. Other feedback included requests for additional detail. She has rewritten several of the examples and still has more work to do. She will post a new version over the weekend and have questions for the group at the F2F.

>>>>>

7. Attendance Update

We made quorum.

8. Conclude meeting

Abbie asked for a motion to conclude.

There were no objections

The meeting was adjourned.

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

Chat room log

abbie: Passcode: 637 218 8139

Int'l Toll: 1-980-939-6928

abbie: agenda

abbie: 1. Roll Call

2. Agenda review and Approval

3. Approve Minutes

4. Presentation by Shahrokh Shahidzadeh,  Intel on endpoint uses cases

  Slides are to be submitted to the TC

5. F2F meeting details update.

Day 1: Wednesday, 14 March 2012, 01:00pm to 05:00pm ET

NIST, Gaithersburg, MD, Lecture Room D.

CHAT ROOM

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

Many thanks to Bank of America to sponsor the call (It is the same bridge as the bi-weekly calls)

Passcode: 637 218 8139

Toll Free: 1866 222 6652

Int'l Toll: 1-980-939-6928

Day 2:  Thursday, 15 March 2012, 09:00am to 05:00pm  ET

CAs Washington DC office. 1401 I Street, NW, Suite 1220.

CA shares their suite with a company named Travelport, and CAs name is not on the Suite.

Visitors can ring the bell and the front desk assistant will let them in.

If folks are taking the Metro, the McPherson Sq. Station is directly across from our office.

We do not have visitor wireless access here in this office, so if folks need connectivity,

theyll need to bring a laptop card or have a Mifi.  (Mary will bring a Mifi.)

CHAT ROOM

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

Many thanks to Bank of America to sponsor the call (it is the same Bridge as the bi-weekly calls)

Passcode: 637 218 8139

Toll Free: 1866 222 6652

Int'l Toll: 1-980-939-6928

6. Mary and Editors to provide an update of Committee Draft

7. Attendance Update

8. Conclude meeting

anonymous morphed into Ed Coyne

Mary Ruddy: anonymous, please sign in uing setting

anonymous1 morphed into Kevin Mangold

Massimiliano Masi (Tiani Spirit): Hello everyone

anonymous morphed into Mike Davis

anonymous1 morphed into shahrokh S.-Intel

Gershon Janssen1: Where can I find the slides?

Gershon Janssen1: Is there a link to them?

Gershon Janssen1: Ah, just received them.

abbie: just uploaded the document at http://www.oasis-open.org/apps/org/workgroup/trust-el/documents.php?folder_id=2575

Shaheen Abdul Jabbar: how do you manage re-provision of the device?

Shaheen Abdul Jabbar: can the device be used by multiple users?

Thomas Hardjono (MIT): Hi Sharokh, what about the TPM.  It has a device identity built-in called the Endorsement Key (EK) credential. Plus it has a number public key pairs that can be used to interact with the outside world.

Thomas Hardjono (MIT): By SIM do you mean the U-SIM smart card technology?

Thomas Hardjono (MIT): ok thanks.

Thomas Hardjono (MIT): I'm shocked!!!

Dale Rickards: I apologize but I must leave the meeting early due to another meeting.

Kevin Mangold: Mary, what is the name of the paper again?

Kevin Mangold: Never mind, I found it: NIST IR 7817 - Credential Reliability and Revocation Model for Federated Identities

Thomas Hardjono (MIT): Bye all.

Massimiliano Masi (Tiani Spirit): bye

Notes for the call of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee

23 February, 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 - y

Bob Sunday

Brendan Peter, CA Technologies – y

Carl Mattocks, Bofa

Cathy Tilton, Daon - y

Charline Duccans, DHS

Duane DeCouteau

Colin Wallis, New Zealand Government

Dale Rickards, Verizon Business

David Brossard, Axiomatics

Dazza Greenwood

Debbie Bucci, NIH

Deborah Steckroth, RouteOne LLC

Detlef Huehnlein, Federal Office for Information

Don Thibeau, Open Identity Exchange - y

Doron Cohen, SafeNet

Doron Grinstein, BiTKOO

Ed Coyne, Dept Veterans Affairs - y

Ivonne Thomas, Hasso Plattner Institute

Jaap Kuipers, Amsterdam - y

Jeff Broburg, CA

Jeff Stapelton – y

John Bradley - y

John "Mike" Davis, Veteran's Affairs

John Walsh, Sypris Electronics

Julian Hamersley, Adv Micro Devices

Kevin Mangold, NIST

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

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

Shahrokh Shahidzadeh (Intel Corp)

Tony Rutkowski

Thomas Hardjono, M.I.T.

William Barnhill, Booz Allen Hamilton

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

2. Agenda review and approval

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

Don asked if there were any additions to the agenda. There were none and we proceeded with the agenda.

3. Approve Minutes

We did not approve the minutes from the previous meeting as there wasn’t quorum.

4. Discussion by John Bradley on how SAML relates and doesn't relate to our TC's mission

Don said we need to provide an update on various submissions and also context for our work.  One way of doing that is to get an update from one of the technology thought leaders in this space. The other thing we can spend time on is making sure we have a strong agenda for the upcoming F2F meeting in March. It will be an important week as NSTIC, IDtrust and ISOC activities will be going on.

Don asked John to start off with some remarks an SAML and other protocols.

John said he was not exactly sure what was wanted. He responded to an email about whether particular bindings of SAML effect LOA. The answer is not really, sort-of. One of the problems with SAML is that it is an overused term. You might as well say you were going to log in with HTTP. Saying SAML doesn’t refine it very much. Could be SAML assertion, and or SAML binding. They all wind up being different problems. That is one of the reasons FICAM created the profiles. The binding doesn’t tell you if the assertion is symmetrically signed, or other things you might need to know to evaluate the assertion or assertion provider.

Some of the academic federations’ manual pair wise approaches don’t scale. The security services TC is working to improve the binding between trust frameworks and entity attributes so SAML implementations can look to see if they should trust other ones even though they are not directly part of their federation.

The SAML profile is more important than the SAML binding. There are particular SAML problems, such as holder of key binding. If you want to get an LOA-4 assertion, according to 800-63 you need to use holder of key. So not all SAML bindings work with all LOA’s. But for LOA-1 to 3 they are generally compatible. The thing that is important for this working group is figuring out how the dynamic configuration is configured. We must be able to trust the identity assertion of an issuer and whether the attributes they are asserting are authoritative. One of the issues of trust elevation is to determine if the thing used to elevate the trust is trust worthy. The metadata is what elevates the assertion. That is usually done through some certification or contractual relationship. Certainly SAML is not unique to use metadata. OpenID and WS-security can also use it to some extent. Some SAML implementations don’t handle metadata problems.

John is fighting with vendors to get them to implement some of the optional parts of SAML that are needed for larger implementations. You can have an entity attribute of FICAM LOA-3, but if the software can’t actually recognize that attribute in the metadata and configure itself to know it can trust the assertion from that provider, it doesn’t do you much good.

Cathy asked a question about auth context. Last time she check ether is no auth context for biometrics. Has this changed?

John replied auth context has changed over time in SAML. At one point people thought RP’s cared about the details. Experience has shown that RP’s don’t actually have the ability to understand the details about auth context. So there has been a movement to use class reference. FICAM LOA-3 is an example, a single URI that points to a standard that has to be met. This hides all the details (e.g. was it a hardware token or a RSA token or a smart phone. that was used as a second factor and the details that the person provided in identity proofing, and other details that might go into a detailed authentication context.)

One of the early OASIS docs went into details about primary auth mechanism, but to his knowledge no one has used it in the wild. Most software platforms RPs use can’t even deal with a single auth context. Certainly inside an enterprise, people may use more sophisticated things. But in large federations, he hasn’t seen it.

John said certainly amongst the hardware vendors, if we are doing OpenID 2, every single auth hardware vendor wants their specific devise listed as an auth context. In reality, we gave them an extension so they could define it. Only two things have ever been used, Yahoo OpenID, which does not take responsibility, and FICAM LOA-1. So for a RP to trust an assertion from a third party knowing the detail is not necessary all that useful. If we get into an area of doing step–up, then probably we will start wanting some combinations. So if you are capable of knowing what [credential] was used first, you can use something different for your step-up.

Bob wanted to put in his two cents. His systems are very much based on reading an assertion level and auditing credential providers to ensure that they are meeting requirements, but leaving techniques, (biometrics, etc.) to the provider, so if the technology advances or requirement get stiffer, they can continue to monitor that. He thinks LOA is very important to auth context. They have laid contractual requirements on their vendors.

John said he typically sees people wanting AuthnContextClassRef, i.e. a technology change.

Peter commented the AuthnContext provides a layer of abstraction that protects the third party app.

John replied, so yes, SAML has changed over time. The SAML auth context assertion is either hopelessly complicated or incomplete depending on your perspective.

The class reference is a URI that points to a set of rules. There is a FICAM LOA-1 auth context that can be different from a Canadian one as their rules about validation certification, aren’t exactly the same yet. AuthnContextClassRef really maps more to levels of trust frameworks. That is a natural thinking for them to point to as it includes technology and liability. Pointing to 800-63 level 1 isn’t necessarily all that useful, (useful but not the whole story). You probably want to know more about who said they were qualified to make that assertion and what were the liability rules. In the Canadian case there are some number of gateway providers and some number of issuers that are approved thru the process, so there is a chain of trust that goes back to the Canadian government that hopefully gives some confidence in the assertion so not everyone needs to have a pair-wise contract. The ability to dynamically express and configure enables them to be more dynamic than configuring by hand. If not dynamic, then it is only easy to support one identity provider. But if have a large pool of identity providers with different levels of trust working together, being able to dynamically configure providers as they come in and out of the ecosystem will be important.

Bob said there is one other thing that is important. The concept of step-up isn’t in the auth context. If you are working in a multi credential provider environment, the request may end up at differ providers: 1-2 at one provider, and 3 at another. So the concept of step-up and LOA isn’t resolved yet. To him step up says you stay with the same credential provider.

Bob said he is speaking more to the behavior. If someone has a LOA credential at a different provider, if just ask the first provider, don’t just want to get a negative response, want option of going to other providers.

John said that is why you have those proxy gateways. It is more of a business /org issue to see if individual provider will change. That is not typically behavior. You would have to train a user to tell their LOA-1 provider who their LOA-3 provider is.

It was commented that is was more likely a broker would handle that.

John said the advantage of the broker is the user is probably using the broker more.

John said there is nothing in SAML or OpenID Connect that prevents you from doing step-up. It is more a matter of figuring out how to do it so that it makes sense to the service. There is a separate project, Account Chooser that has an agent that could also work with SAML. That is different from a gateway service. The down side of gateways is the more info they track to be useful, the more of a privacy concern they are, and the more of a honey pot they are. So gateways are a mixed blessing.

Peter commented that you can, depending on how they are implemented.

John replied if they are completely stately, they may not be able to.

John said that account chooser is completely stateless.

Peter commented that part of this conversation has gotten into nitpicking and is irrelevant for our purposes. If we have LOA-2 and LOA-3, the gateway can just engage a trust elevation process. Just because someone has a LOA-3 credential doesn’t mean that the gateway needs to look for it. It is an over complication.

John said getting the LOA-3 credential is more straight forward.

Peter replied that the problem is that while this seems straight forward, it is not because of privacy So it is more straight forward to engage KBA and obviate the fact that someone has LOA-2 and LOA-3 credentials.

John said it is probably better to have an LOA-3 credential that can be used as LOA-2, and have an RP that asks for LOA-3 when it really need it, but not ask for that extra factor at LOA-2.

Don paused the conversation to note that Brendan and Anil had joined the call.

John is going to think about step-up more before the F2F.
Don would like to carry this topic in the F2F: crossing protocols and step up in a trust framework.

Don made a note to the record that we will pick-up on this at our F2F.

Our next meeting will have a presentation on endpoint uses cases by Shahrokh Shahidzadeh, Intel

5. F2F meeting details update.

Peter said that the NSTIC meeting conflicts with our F2F meeting on the 15^th. Yesterday the decision was made that there will be an all day meeting at the commerce department. It will not be like a proposer’s workshop, but a one day discussion of the published guidance /recommendations and draft bylaws. There would be morning and afternoon breakouts sessions. The proposers’ workshop for the secretariat FFO will be held as a WebEx telephone call in March at a date to be determined.

Don asked for more context about NSTIC‘s goals for this one day discussion.

Peter explained that the NSTIC program office published a set of recommendation about how to implement a governance model a couple of weeks ago. There is a set of draft bylaws that goes with it. The office is going to award a 2 year grant to some entity to be a neutral, managing executive secretariat to call this government body into existence. It will be run along the lines of the draft bylaws for two years. The office assumes there will be a number of applicants to be the disinterested secretariat, and the governing body would be instituted according to the guidelines. So this meeting on the 15th is a discussion of the guidance that has been published and selected topics and implementation issues.

Don commented that is a real change and the quick and important thing is that disrupts the plans for this committee to have a F2F meeting that would have taken place the afternoon of the 15^th. So we need to go back to the drawing board and see if we can’t get back to the committee with a substitute date or look for another venue where we can have the F2F.

John commented that he is available on March 16^th.

Brendan offered that to the extent we need to move the meeting, CA can be flexible as the host.

Don asked Brendan if he could take an action item to see of if he can host a meeting on the alternative date of the 16^th.

Brendan said he will reconfirm and send a note to Mary.

Don said this change is tentative (moving the second day of the meeting from the 15^th to the 16^th.) We will need to pole the TC to see if they agree.

6. Mary and Editors to provide an overview of Committee Draft of first deliverable

(http://www.oasis-open.org/apps/org/workgroup/trust-el/documents.php?folder_id=2598)

Mary commented that the latest version is available above. The planned schedule is as follows:

>>>>>

Mary commented that a draft had been distributed to the editors and that she is expecting feedback from them by end of day Friday. She is also still waiting to hear back from a couple of people who were planning to submit examples.

Don asked Peter for his comments.

Peter said he is working on it and working through it. He keeps going thru the items to make sure we don’t have redundancy in the methods and techniques. A lot of people have submitted things that are similar. I think we need to boil down to one example per method. There are a couple of method examples where folks seem to miss the point in their own examples.

Peter said he will have written feedback by EOD Friday.

Don asked for any other feedback. As peter indicated, the challenge we face as a committee is pulling in as much rich content as possible. There is always a balance between propriety interests and the committee interest. This goes to our mission of getting as wide a range of input as possible with duplication.

Peter said that one of the issues is duplication and repetition. It really does give a sense of what techniques are most widely used.

Don said that is a good point. We want to talk about depth as well as breadth.

Mary commented that this all depends on what people want to make public.

Peter replied that yes, we are always at the mercy of perceived disclosure. That point is exactly on target.

Don said we will get back to the TC to see if this notion of moving the F2F by a day. He asked if there were any other comments or questions.

Shaheen said that he prefers the F2F is the originally scheduled Thursday rather than Friday.

Peter said that an argument could be made that those who are working the trust-el are less concerned about the NSTIC governance, many of us do overlap.

Don said we will try to take a poll. Abbie, Mary and I will determine a way to sort that out as quickly as possible.

Don wanted to note that we will be hearing from our colleagues at Intel at a later date. We will reschedule that and wanted to thank John Bradley for his update on SAML and OpenID Connect and overview of how identity standard protocols do step up.

Don commented that we may want to publically shame those who haven’t yet contributed their method examples.

Mary replied that they aren’t on the phone.

7. Attendance Update

We did not quite achieve quorum.

Abbie commented that by the end of the next F2F we want to have something to approve and start working on the second deliverable.

Abbie noted that it was 11:00.

8. Conclude meeting

Don said since this was an informal meeting he will call an end to the meeting. We will get back to you as soon as possible on the logistics of the F2F.

Don asked for a motion to conclude.

There were no objections

The meeting was adjourned.

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

Chat room log

anonymous morphed into Suzanne Gonzales-Webb

abbie: hi will be on the chat room only when i can

Don Thibeau Open Identity Exchange : abbie I understand you will not be at RSA next week

anonymous morphed into Jeff Stapleton

Don Thibeau Open Identity Exchange : Some of you may be interested in an upcoming OpenID Foundation workshop in London  http://oidflondon2012march.eventbrite.com/

AnilSaldhana(RedHat): Mary, please add me to the roll please.

Don Thibeau Open Identity Exchange : any other questions on SAML and /or step up authentication in multifactor authentication strategies?

Don Thibeau Open Identity Exchange : please advise Mary Ruddy mary@meristic.com of your availability/feedback re: agenda items for the face to face meeting now scheduled for March 16 in Washington DC

trust-el message