SV_MEETING_TITLE -- 24 May 2011

<josephboyle> Good morning

<scribe> scribe: benadida

<benadida> halpin: starting with intros

<benadida> trentadams: internet society

<benadida> ... mikejones openid foundation

<hodges> so how come the irc founders/fathers/moms in their infinite wisdome decidced to use a slash to denote port rather than ":"

<benadida> scribe is missing some folks

<benadida> Tyler Close from Google

<benadida> Chris Messina from "the internet"

<benadida> ... see the attendee list :)

<benadida> halpin: agenda http://www.w3.org/2011/identity-ws/agenda.html

<dveditz> hodges might depend on your client? mine uses ':' for port

<benadida> ... note a special session at end of day to gather results and define next day's agenda

<benadida> ... hoping for consensus around areas of further discussion

<benadida> ... [discussing second day agenda]

<benadida> halpin: possible outcomes: charter, other workshop, ... we don't know but we'll discuss.

<benadida> halpin: resuming at 10:30

<JeffH> dveditz -- ja u may be right -- plus dcrocker points out that / may predate :

<JeffH> time to grep RFCs.....

<benadida> Trent Adams starting "Learning from the Past"

<benadida> adams: PC debated starting with past, or start with reqs. Settled on starting from past.

<benadida> ... not trying to beat up on anything. Pick up what we can do.

<benadida> ... be wary of reinventing the wheel and needing new infrastructure.

<benadida> ... consider the how to get there from here.

<benadida> ... lightning rounds, 5 min each, 4 talks, in order of program

<benadida> ... first up, Bob Morgan, UW / InCommon Federation "Browser support for identity federation with many identity providers " http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_29.pdf

<bblfish> Is there a recommended web service to connect to this irc channel for people without IRC clients?

<karen> Speaker: RL 'Bob' Morgan, University of Washington/InCommon Federation

<benadida> bobmorgan: coming from research and higher ed, IdP discovery primary challenge.

<benadida> ... here's an example of a bad UI for logging in: Athens on Elsevier. Big drop-down of id providers.

<benadida> ... everything is wrong with this.

<benadida> ... maybe the problem is SAML, old fashioned. SAML2 is 6 years old. New protocols to the resuce? OpenID?

<benadida> ... OpenID: cool logo. entering a URL didn't really work out in practice (both clicking and entering URL)

<benadida> ... InfoCards: time put into logo for people to click, id in the browser, lots of UI work, some UX problems.

<benadida> ... needs to be a way to move incrementally from existing uname/passwords.

<benadida> ... showing defined set of IdPs with JanRain + escape clause of OpenID

<benadida> ... showing more examples Kantara/Google ID Toolkit, show a few default buttons, then "other"

<PHB> The problem with infocards etc is that it does not save a user time to have an easy login for 10% of the sites they use, it only gets easier if they can use the easy log in at every site without exception

<benadida> ... are there browser features that can help? IdP discovery in browser. XRD? JSON?

<benadida> adams: next, Paul Trevithick "Identity In The Browser at 5. Lessons learned " http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_41.html

<benadida> trevithick: 5 minutes to talk about 5 years.

<benadida> ... InfoCards UI, card picker in browser. User Auths to IdP, token eventually posted back to RP.

<benadida> ... things we got right:

<benadida> ... user-centric and decentralized architecture

<benadida> ... identifiers are subsets of claims attributes

<benadida> ... support self-asserted and third-party asserted

<benadida> ... extensible schema

<benadida> ... claims in URI form

<benadida> ... personally would prefer moving to dereferenceable claims URIs

<benadida> ... end-to-end crypto architecture (message transport, audience restrictions)

<PHB> Why does the user care about identity? I don't think they care in the slightest about making it easy for Facebook to monetize them. So how is identity 'user-centric' when it addresses issues the user does not care about?

<benadida> ... separate token format and network protocol

<benadida> ... browser initiated, not RP inititated, otherwise susceptible to phishing.

<benadida> ... minimum disclosure of attributes.

<benadida> ... and pseudonyms (PPID)

<benadida> ... now for UX

<benadida> ... support for multiple identities, good

<benadida> ... show only identities that match site requirements - no NASCAR problem.

<benadida> ... roaming support, initially bad (in client), then roaming support added by putting cards in cloud

<benadida> ... cross-browser cross-platform, not fully done by MS, problem.

<benadida> ... we got unmodified browser support wrong.

<benadida> ... users don't care about protocols, but we should have built technology to migrate from today's legacy.

<benadida> [scribe missed some tradeoff bullet points]

<benadida> ... driving adoption: worry only about the web sites, put all energy there, we suffered from MS domination.

<benadida> adams: next Brad Hill "Identity in the Browser - Avoiding Common Flaws" http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_37.pdf

<benadida> bradhill: spent a lot of time breaking things, looked at lots of auth systems (for hire, etc.)

<benadida> ... found lots of similar bugs across systems

<benadida> ... different from pure design problems.

<PHB> I could never understand why there was so much concern in OpenID to make it easy to deploy an IDP, to the point of making it possible to deploy an IDP without functioning DNS and then wrecking the usability of the scheme to support IDP providers that should probably have been told they can't be an IDP

<benadida> ... working to coalesce pentester intuition and help train others.

<benadida> ... presented a paper at RSA. 8 top flaws (see paper)

<benadida> ... bearer tokens (unconstrained delegation)

<benadida> ... [and more, see paper, going too fast for scribing]

<benadida> ... be careful about only relying on SSL.

<benadida> ... trying not to revert to lowest common denominator of cookies and cookie-like tokens.

<benadida> ... recently joined Paypal, but here unaffiliated. Be voice of what could go wrong.

<benadida> adams: next Frederick Hirsch (Nokia) Importance and Impact of Requirements on Technical Solutions for Identity http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_31.html

<benadida> frederickhirsch: one lesson from Liberty/SAML/SOAP WS-Sec: simple reqs have large repercussions

<benadida> ... co-chairing Device API WG

<benadida> ... added policy (XACML) for access to devices/data

<benadida> ... Google asked 'so who's going to write policy?'

<benadida> ... also, how to handle revocation? simple conceptually. harder to do it.

<PHB> Well maybe the solution to privacy is not to do 'identity' at all.

<PHB> What users want is a solution to their problem of too many accounts, usernames and passwords

<benadida> ... some concrete lessons

<PHB> What dotcoms want is to set themselves up as gatekeepers for that and the price of admission is to hand over your personal data

<benadida> ... need legal and business considerations in addition to tech

<PHB> How about a scheme where the user just gets what they want without handing over their personal data to anyone who does not have a really good reason to get it.

<benadida> ... discovery is a key thing to worry about.

<benadida> ... it's not clear what "informed consent" means

<PHB> Every identity scheme should have a button the user can press labelled 'create fake identity for this account'.

<benadida> ... controlling which attributes are released.

<benadida> ... general requirements: universal implementation, usability, user's choice

<PHB> Errors we have not addressed: Assertion that Web sites want to control the user experience, not true and totally irrelevant if true. I own my browsing experience, not the Web site.

<benadida> ... need incremental adoption, combination of tech and non-tech.

<benadida> ... privacy by design is a huge topic, harder than it looks

<benadida> ... distributed system is important, liberty had centralized system

<benadida> adams: we have 30 minutes to extract meaningful information from lessons of the past.

<benadida> ... let's see if I can summarize

<benadida> ... Paul talking about infocards, great design, fell down on usability issues.

<benadida> ... Bob a bit of the same usability issues.

<benadida> ... Brad thinking about bits/bytes/crypto

<benadida> ... Frederick brought policy in.

<benadida> paultrevithick: using "usability" very broadly, yes.

<benadida> ... i.e. not having it available on user's specific platform.

<phunt> How about must be WANTED by the user.

<benadida> ... adams: should we consider "must be usable" as a req? Sounds trite, but important.

<benadida> paultrevithick: we're trying to annoy the user as little as possible. User doesn't care about what we're talking about.

<benadida> dave?: saying 'it's usable' isn't a usable statement.

<benadida> ... needs translation into pragmatic. What is the benefit to the user/administrator?

<JeffH> dave? == Dave Crocker

<benadida> carlhewitt: wondering if 'browser in web kiosk' is in scope? If so, how can we possibly win?

<benadida> ... can we agree to punt on that?

<benadida> bobmorgan: airport kiosk might be a problem if no degree of security.

<benadida> bradhill: two concerns here: completely untrustworthy platform, but that's not what user thinks: pre-provisioning is issue.

<benadida> chrismessina: 3 points:

<benadida> ... didn't hear much about users. What is the product?

<benadida> ... what are the user-facing experiences? Login procedure is zero value. Enabled verbs are what's interesting.

<benadida> ... what do you unlock with identity

<benadida> ... (2) timing is important.

<benadida> ... timing is relevant because we have this data for users to manage/exchange

<benadida> ... (3) worth looking at existing providers (Facebook, Google, Twitter)

<benadida> ... how do we align native interfaces with these?

<benadida> bobmorgan: great that we're converging on UI

<benadida> ... big step forward from even a couple of years ago.

<benadida> philiphallambaker: I hear 'how do we turn the user into a product?'

<benadida> ... we're not trying to make a business here, we're trying to solve the user's problem.

<benadida> ... every site (system?) should have a "create new identity"

<benadida> ... prefer not to talk about identity at all

<benadida> francesco?: infocards needed desktop app, right?

<benadida> paultrevithick: eventually moved to cloud

<phunt> Sometimes it is important to be able to recognize your returning customers even though you don't care to keep personal information

<benadida> francesco?: maybe lesson to draw is that it should be in the browser.

<benadida> ... maybe it doesn't work when it's not in the browser?

<benadida> benadida: do you mean in the browser or in web content?

<benadida> francesco?: diff?

<benadida> michaelhanson: compiled into browser?

<benadida> paultrevithick: now we're looking at the minimal in-browser functionality? We would do a very diff job today.

<benadida> bradhill: isn't browser becoming less important?

<benadida> ... apps on our phone, etc.

<benadida> ... browser isn't going to be the only platform

<JeffH> this is David Chadwick speaking now

<benadida> davidchadwick: I think we're talking about authorization, not identity.

<benadida> ... cf Sony, can we get away from providers storing credit cards? business case now.

<benadida> Dan?: this has been tried many times in the past. Problem is no perceived need on part of user.

<JeffH> Dan Schuster (sp?)

<benadida> ... if it's difficult to use, even w/ perceived need, users deterred.

<benadida> ... a lot of us want improved security, but that's least important to user. thus failure.

<benadida> bradhill: users don't know how to ask about or express security requirements, but they still have important expectations.

<benadida> frederickhirsch: users don't care about privacy until things go wrong. They have expectations about norms, etc.

<benadida> samhartman: I think users care a lot.

<benadida> ... some deployments in enterprise have worked well. Sometimes mandated. Other times significant usability advantage, e.g. activedirectory, shared profiles.

<maryhodder> what does "it" and "this" mean.. there are too many pronouns.. please define what you mean by "it"

<benadida> ... security isn't driver, but users do find some aspects compelling.

<benadida> michaelhanson: when we talk about adding to browser, consider null hypothesis: providers have built identity using SSL, cookies, forms.

<benadida> ... by getting creative with SOP, redirects, etc. they've constructed vast identity systems.

<benadida> ... if we make change to browser, enable another possibility space, clever developers will figure out 'what they can do with it'

<benadida> ... what's smallest change that makes a difference?

<benadida> tylerclose: somes lessons learned in last 10 years may not be that important anymore

<benadida> ... e.g. backwards compatibility with older user agents

<benadida> ... also, important not to have single vendor, but today we have single vendor communication platforms that overthrow dictatorships.

<dveditz> dsinger: 10-15%?

<benadida> ... [missed a bit of the last argument by tyler close]

<maryhodder> @benadida i disagree that we have single vendor communication platforms overthrowing dictatorships.. that

<maryhodder> @benadida that's mythologizing things.. those dictatorships fell because people spent years organizing and planning

<benadida> carlhewitt: if we only solve id in browser, we have failed, or browser in trouble.

<benadida> ?: degradation of experience is important, e.g. read-only Facebook at airport.

<maryhodder> @benadida yes. we have silos.. that's the problem.. but i wouldn't conflate silos with the ways we describe political changes

<benadida> ... key takeaway from paul trevithick: adoption.

<dveditz> dsinger: actually statcounter is showing 4-5%

<benadida> ... and to biz model question - for that (adoption?) reason, business is important

<benadida> ... consistency of experience: different sites are completely different experiences. Consistency would be helpful.

<benadida> ... that is value

<bblfish> I see there are speaker queueus and stuff. Is there a teleconf number?

<benadida> [note to @maryhodder: I'm only scribing :)]

<fjh> /me dsinger was not speaking before

<dveditz> statcounter tends to count IE lower than netstats fwiw

<mohawk> People will trade "usability" for security for certain use cases.

<benadida> mikejones: 2 takeaways from cardspace effort

<maryhodder> @benadida.. sure.. just want to caution about the ways we mythologize tech and who drives things.. as examples of problems or solutions

<benadida> ... (1) we (ecosystem) weren't solving a top-5 pain point. To Paul's point: focus on relying parties.

<JeffH> @bblfish -- dunno -- i don't see any mics in the room

<benadida> ... (2) usability was a big problem. If we don't get solutions to identity that are compelling to the end-user.

<benadida> ... Also echo Carl's comment that solving problem only in browser, we're not solving the problem.

<JeffH> this is "RLBob"

<dveditz> we could ask, there might be some mics we could bring in for later sessions

<benadida> bobmorgan: choice of WS-* was a barrier to deployers.

<JeffH> @dveditz: wud be good to do i spose

<benadida> ... we're getting to convergence of more web-based stuff, OAuth, JSON, ...

<benadida> ... protocols do matter to get things out there.

<benadida> dsinger: we've trained the user to make the wrong direction. Are certs hopefully polluted and therefore dead? Are we going to make the same mistake again

<benadida> davecrocker: users do care. they may not be competent about details, but of course they care. reactively or proactively is our problem, not the users'.

<benadida> ... "perceived need" - if we start there (and if not there educate), ... [missed the conclusion of that point]

<benadida> fjh: not just random transactions, preexisting relationships. Don't need arbitrary identity systems for any relationships. Should simplify.

<benadida> maryhodder: can we be more specific when say "it" and "this"?

<benadida> ... different people saying different things.

<benadida> ... be more aware, define.

<karen> +1 define the antecedent

<benadida> chrismessina: few more comments.

<benadida> ... liked Paul's comment about double negatives.

<bblfish> (the scribing seems good, though of course without being able to hear I am not in a position to judge)

<benadida> ... we're not looking at things not happening because of identity wall.

<benadida> ... so what kinds of new activities would you see on the web with identity?

<benadida> ... status quo of identity on the web is not sufficient, not ok. Something should be done.

<benadida> ... valid to ask what is a browser?

<benadida> ... each mobile app I use is a browser

<benadida> ... more and more, I have to sign in to those apps independently.

<benadida> ... now have to manage more accounts, unless using Twitter/Facebook.

<mohawk> +1

<bblfish> of course: distributed social networks need identity

<benadida> ... if that's more and more common, we should build identity as a platform, that users take for granted, for browsers/apps.

<bblfish> distributed social networks = Social Web.

<fjh> Form fillers seem to work?

<benadida> adams: common themes

<benadida> ... reuse of existing solutions

<mohawk> definitely +1 on reuse

<benadida> ... mobile

<benadida> ... diff between in-page and browser chrome

<benadida> ... (to mary's point, let's keep that clear.)

<benadida> ... security, prioritization of it.

<benadida> paultrevithick: definitely don't want to put all transaction info in front of user. See OAuth.

<josephboyle> +q

<benadida> ... rational actor model doesn't work.

<JeffH> to clarify part of what chrismessina said: smartphone apps are often just a web app running in an execution environment that doesn't look like a traditional browser, but is under the hood

<benadida> fjh: doesn't know what mobile means.

<benadida> ... maybe not a separate category.

<JeffH> @fjh -- u talk a bit too softly :)

<benadida> dsinger: also mobile single user.

<benadida> paultrevithick: irony is cardspace was outside of browser, did more.

<benadida> adams: more themes

<benadida> ... backwards compatibility vs. graceful degradation

<mark> we should also consider devices like TVs - a lot of these use web tech for apps and UIs

<benadida> bradhill: also, who are we giving work to, what are incentives?

<fjh> S/ mobile means/mobile means, in that we see mobile laptops,ipads etc, apps on terminals etc/

<benadida> bradmorgan: economics have to work to make change happen

<benadida> benadida: some comparison between solving for mobile/desktop apps and solving airport kiosk.

<benadida> ?: mobile = sim card

<benadida> crowd: NO

<htschofe> Next session: Definitions, requirements and scope

<htschofe> Harry is going through his introductory presentation (slide he had gotten from Eve Maler)

<josephboyle> I think possibly the most important requirements question is: Which functionality needs to be baked into the browser and which does not? We should keep the baked-in part as well-defined and minimal as possible, both to make it easy and fast to implement in the browsers, and to allow sites to continue to customize and evolve the non-baked parts.

<tlr> ScribeNick: htschofe

Trying to reduce the scope. In order to move the world forward we have to pick specific items.

If we don't get this right we will cripple our entire conversation.

John Linn is on the stage talking about Goals Constraints, and Issues for Identity in the Browser.

<tlr> JohnLinn: talking about goals and constraints

http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_2.pdf

<tlr> ... issues for identity in the browser

When solving distributed problems you need to put the solutions into the right place.

Browsers are in a good place because user's interact with them. Browsers don't act autonomously

Browsers can enforce policies. They may act more autonomously with regard to identity in the future.

User's need to manage their identity elements (credential management and privacy)

We have an opportunity to-do better than just managing passwords in a different way.

NIST provides good guidance with SP 800-63

The eco-system is more complex than just a two party interaction for authentication but we also have delegated authentication

John talks about the protocol adoption and lists three criteria

* value to site operator

* compelling value to users

* regulatory mandates

Protocols must be gradually deployable.

Next: Platform concerns

The bad side-effect of credential exposure has to be avoided.

Challenge - improve interoperability without fragmented confusion

Aaron Brauer-Rieke (CDT) is going to talk next.

No slides available.

Aaron wants to talk about privacy related topics; in particularly about privacy principles.

Aaron is happy that even the folks in the room don't have a shared understanding of identity.

The principles are described in the paper http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_24.pdf

Requirements:

* Proportionality

* Don't save the privacy discussion for later.

* Diversity and Decentralization

He also points to the OECD/FTC privacy principles.

Privacy is a big issue and not going away. There is now a lot of regulatory attention to the privacy topic. Privacy is part of the NSTIC effort.

CDT is fairly agnostic on the scale of the identity solutions.

Jeff Hodges is next. He will talk about his paper "Putting the Cart Before the Horse"

http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_55.pdf

Today's credentials are re-usable (and shared secret) and will be put by user's into every form.

Smartphone adoption is increasing. We need to think differently about the smartphone from a security and identity.

Also other devices will soon be running Web servers, such as appliances, industry control systems, cars, etc.

All these systems are vulnerability to Web security vulnerabilities.

What is a Web browser?

Is an execution environment for mobile code.

<bblfish> I wonder if anyone can fix the problem of the paper on the Agenda "The WebID Protocol and Browsers" is broken on the agenda page http://www.w3.org/2011/identity-ws/agenda.html

Therefore, we need to re-think our goals:

* How to mitigate CSRF?

* How do we get around the new world of smartphones?

<bblfish> It should be pointing to http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_22/webid.html

<scribe> * New paradigms for security indications?

* Can we get more consistency across major browsers regarding the security of the code execution platform?

<scribe> New Talk: Stephen Schultze & Thomas Lowenthal

Thoughts on Trust Infrastructure, User Interface, and Legal Issues: http://www.w3.org/2011/identity-ws/papers/idbrowser2011_submission_50.pdf

Their approach being investigated is an incremental change rather than a clean slate approach.

Thomas starts his talk about trust infrastructures

He talks about the PKI model in the browser. The trust decisions are made be the browser vendors.

<PHB> No, the CA also has the task of managing revocation

Undesirable consequence: Any CA can issue bad certificates. How much checking should the CA do before issuing different certificates?

Web of Trust model is a more user-centric model. The level of trust is variable. The disadvantage is that user's need to make all the decision. It is technically challenging to implement.

<PHB> Web of trust hits the Moore bound on minimum diameter graphs. If everyone in the world validates 10 other people the absolute smallest diameter of the graph possible is 7

A third model that is more valid is a delegated trust model. One that is used by DANE.

<PHB> Expected diameter is about 14. So that means that the Web of trust introduction is really weak.

http://datatracker.ietf.org/wg/dane/

<fjh> User decisions can work in an environment with accountability? In physical world lots depends on accountability

Idea is to attach certificate to the DNS. Security provided by DNSSEC

This model shows a lot of promise in comparison to the other models.

Now, Stephen is back on the stage talking about user interface.

(previously he referenced a blog post about NSTIC; it is here: http://www.educatedguesswork.org/0

http://www.educatedguesswork.org/

Stephen shows the different UIs in browsers for security properties.

Stephen argues that consistency is good. Competition is bad in this space.

Legal issues: Stephen argues that there is not much monetary liability with CAs.

We need clear assurances that user's understand and reflect reality.

Finding the solutions that provides the right level of legal regime and liability obligations.

Taylor: User's don't look up indicators in the chrome. All the browser compete for UI and so the user's are not sure what they should be expecting.

Stephen: W3C tried to work on the UI space and failed (group is the Web Security Context)

Jeff: Points to implicit authentication using mobile phones.

He referenced these papers in his position paper.

Karen Meyers: I am not sure about the amount of user testing vendors do. What about the academic community doing these tests?

Jeff: I am not a browser vendor

Mike: RP testing is intense. For them, the conversation flow is important. Turning the inbound request into a customer request is important. They don't publish the data.

Jeff: We have a usability lab. We have talked with them about doing more research in the security & identity area.

Mike: We had a UI research group and also on the browser-presented logins. We also have heatmap data that is published.

Nico: I don't know what the value of the lock icon provides given that the user has no relationship with the CA.
... Who is going to police? How do we go from zero value out of the CAs to getting something?

Thomas: User's shouldn't have to deal with the CAs. User's interact with browsers.

CAs should be accountable to browsers

Nico: CAs will have a responsibilities to those people they sell their certs.
... I believe the way to address this liability and trust issues is for users to exploit the relationships with identity providers

<JeffH> we reference a paper that disucsses the futility of user training

Dave: We as an industry largely clueless about security & usability. The state of the art is pretty weak. We train people 6 months to drive a car. We don't really know what teaching knows and what it does not. When we say we need more user training then we are deferring the problem

<siddharthbajaj> Couple of studies of EV effectiveness -

<siddharthbajaj> 1) http://www.verisign.com/ssl/ssl-information-center/ssl-case-studies/overstock/index.html

<JeffH> S. Görling. The Myth of User Education, Virus Bulletin Conference, 2006.

<JeffH> http://www.gorling.se/files/texts/StefanGorlingVB2006.pdf

I am suggesting that we should not rely on the user understanding the security process.

PHB: CAs also maintain the cert status over the lifetime.
... In many of the breaches the announcement of certificate revocation have been out soon afterwards but the browsers have not processed them.
... We cannot claim that the certificate is the problem but nobody else has other responsibilities.
... We have been pretty good in the CA business in selling certs to servers but not for end users. It turns out that user's don't want to be involved in this cert life-cycle.

Stephen: Of course revocation is part of the process. You are raising the correct larger issue: the participation of the browser in the larger process and having the right type of incentives. What is broken is the meaningful incentive to execute enforcement.

We have no finer-grained enforcement and a good liability model. There is no way to regulate the system. I would like to avoid this problem in whatever identity management system we come up with.

<tlr> I'd say: We don't have mechanisms for fine-grained control that are actually deployable.

I do believe we need intermediaries to offload the talks of users.

David: Points out some common policy of how to handle failures in certificate handling.

Thomas: There is a reason why browsers are doing this. Revocation services are not well maintained and the uptime is not good enough

<tlr> just briefly: I don't think we should analyze the deep details of the browser CA discussion.

<tlr> there's a high-level point here, which is deployability of security protocols

Because this is the normal case browser vendors have implemented a policy that cert revocation checking isn't done

<tlr> Steve's and Tom's lessons for the identity system

<tlr> ... would be more interesting.

David: Browsers should exclude certain CAs that don't behave properly.

Stephen: But then it breaks the web.

?: You can turn on "hard fail" in Firefox to deal with these problems. Since it is not really usable we have to start elsewhere

Carl: The eco-system has changed. The role of the regulator has changed a lot. Whatever solution we come up with it it has to be explained to government people.

Chris: One of the missing things on the Web is being around other people (despite the social networks). One thing therefore to give user's the ability to see what their other friends have done (like exposed certain information).
... The lock is very misleading in the complex protocol exchanges where one site shares data with other sites.

Brad: We should looking at the how to reduce the incentive to attack.

<bblfish> a few things that are going to change a lot: DNS-SEC and Dane https://datatracker.ietf.org/wg/dane/charter/

Tom: Thoughts on the enforcement issues. It is critical to the entire question. Enforcement after the fact (example the Sony case). This can be an enforcement. Given that the concern is so unclear what the liability is I am not sure it works in the identity space.

<bblfish> they should make self signed certs a lot easier to deploy increasing the adoption of server certs

<dveditz> bblfish: yeah, then you just have to trust your registrar.

<dveditz> but at least you don't have to trust everyone else's

Liability before the fact: There we need to regulate every behavior. Everyone has a piece of the puzzle to follow the rules. Getting the consumer to the right thing seems to be impossible.

<bblfish> dveditz: yes, it's an improvement. You always have to trust someone. At least the registrar is in your country. Nothing of course solves everything. Small iterative improvements work best.

Frederick: Talks about the different types of measures of dealing with liability and providing the right incentives. He summaries the previously made discussions.

John: The approaches suggested previously are not mutually exclusive. We need to help users to offload tasks and educate them if they need to understand the important things.

<bblfish> Have people gone to lunch yet?

Don: Points to the trust framework concepts also being pushed by the NSTIC efforts.

end-users, sites, regulatory value-end users

privacy by design

<JeffH> lunch is sposed to happen in a minute

Stephen: Some of the failing in the past in the IdM areas are because the solutions have exclusively being built on a one of these areas technical, regulatory, and policy.

Harry: We have to focus on some extend to look at security mechanisms. There are challenges in the CA system.

Two themes:

* Certs in Browsers

* Security indicators

* Interaction with the regulatory community

(now, they are three themes)

<JeffH> ok

<JeffH> Siddharth Bajaj is holding forth

<hhalpin> like Siddharth: We are trying to recreate a PIN-based system on the NET

<JeffH> on Vision for Browser-Assisted Web Authentication

<nico> hello

<JeffH> proposition is that we hide the complexity under the hoods of our devices, and just remember a PIN for device

<nico> this proposition has been made before

<JeffH> Jonas Högberg (JH) holding forth how

<JeffH> Mobile Provided Identity Authentication on the Web

<nico> we've been looking forward to the day when we could a) count on everyone having a suitable mobile device, b) universal interfaces between those devices and larger, less mobile ones (as well as mobile-to-mobile)

<nico> are we there? we're sure getting closer

<JeffH> this stuff based on Generic Authentication Architecture/Generic Bootstrapping Architecture (GAA/GBA).

<hhalpin> good point nico, I think it's getting closer.

<JeffH> in combination with OpenID

<JeffH> bennies: bridges "web" and "telco" world; stds-based

<JeffH> issues: no GBA-enabled browsers; IDP discovery; terinal (handset) support of GBA ?

<nico> hhalpin: and at what point do we decide to require that people have such devices?

<JeffH> nokia & sony ericsson may have some GBA support, dunno about others

<nico> or at what point can we assume everyone has or can afford one

<hhalpin> nico: I'd have to see market adoption stats first, anyone have any pointers?

<nico> I like to think of mobile phones as a smartcard of sorts

<JeffH> i hear in 3d world that villages will go in together for a handset or two for shared use

<JeffH> Mike Jones holding forth now

<nico> hhalpin: I don't, but don't forget that we'd need global stats, not just first world stats

<JeffH> Emerging JSON-Based Identity Protocol Suite

<JeffH> good thing about stds is that we have so many of 'me

<nico> FWIW, Heimdal has an awesome, open source ASN.1 compiler and BER/DER run-time

<JeffH> so, Mike & friends building new stuff, trying to learn from past, using REST and JSON

<nico> that may be late, but from my p.o.v., it's a bit of a game-changer (suddenly it's much easier to push for new ASN.1-based things)

<JeffH> four specs: JSON Web {Token,Signature,Encryption,key}

<nico> (I'm always amused by the idea of mapping XML schemas to ASN.1 so that PER can be used for "compression")

<JeffH> OpenID Connect is based on this stuff

<JeffH> Hannes Tschofenig holding forth on Browser support for OAuth2

<JeffH> plethora of authn mechs -- what should browsers support ?

<JeffH> can we concoct BestCurrentPractices / guidance for the UI asking for authorization to divulge user's data ?

<JeffH> shall we standardize a JavaScript (JS) crypto lib ?

<JeffH> Mike Perry fro TOR holding forth

<JeffH> too many cookies in browser for user to manage

<JeffH> SaHartans: what do the proposals facility one doing that one cannot otherwise do today?

<JeffH> francesco: (spelling?) IDP can track user, and SPs can too if they collude. (some) govts want to avoid this...

<JeffH> hannes: oauth has multiple flows, could use two party flows to mitigate things

<JeffH> nico: this cage match thing is perhaps not so useful -- what about goals for this workshop?

<JeffH> Trent: we may well not get from browser vendors what we ask as a result of this wkshop

<JeffH> nico: wrt privacy -- what do we not do in public such that it can truly be protected? but traffic analysis would still be available...

<JeffH> Dan Schutzer: we want to get stronger authn out of this effort ? but typically they can be MITM'd ... so want to see is some eech that isn't subjectg to such attacks

<josephboyle> Room is getting uncomfortably hot - could someone adjust thermostat?

<JeffH> hannes: going to have to map to natural person at some point; also strong creds aren't a panacea

<JeffH> siddarth: nist levels today define ident proofing

<JeffH> hannes points out various further facets to all this

<JeffH> nico: need to apply more OS magic authn techniques to browser....

<JeffH> phb: folks should actually explain what their proposals are and how they work -- they are very high level views

<JeffH> Jonas H. noted that GAA/GBA may be the way things in mobile world go....

<JeffH> PHB: perhaps we should have an account manager in the cloud...

<JeffH> hannes: going to have to map to natural person at some point; also strong creds aren't a panacea

<JeffH> oh, he said that before, i had a gui fault here, nevermind

<JeffH> so Hannes is noting that a big issue of acnt manager in cloud is how one authns with the acnt manager

<JeffH> sidarth: can hide auth complexity under hood

<JeffH> netflix guy: we decouple device author and web app author -- solve it with a registratrion dance

<hartmans> And the market will decide multiple mechanisms are appropriate for different situations.

<JeffH> nico: wants market to decide wich way to go

<JeffH> and echos hartmans notion

<JeffH> nico: there needs to be plugable interface, so can plug in mechs

<hhalpin> no mechanism for self-signed cert

<JeffH> dave chadwick: what about self-signed certs? can browser gen certs?

<JeffH> would help with dynamically being able to change personas on the fly ("webid" mentioned)

<JeffH> siddarth: it could be done/generated in browser, or done more traditionally

<hhalpin> I suspect Siddharth is using "webid" in a different sense than say, David Chadwick.

<JeffH> ?: "device id" is the critical thing

<hhalpin> But basically "device id" via certs I think is the common thread

<JeffH> fredrick hirsch (fjh): u mentioned device ids, wanting crypto, does this imply a "trusted computing platform" ?

<JeffH> siddarth: if browser can do this stuff in sfwr, that'll be a win

<JeffH> but html5 has device apis, opens door to using hdwr modules -- but key thing is to have it be extensible

<JeffH> hhalpin: all these approaches are different, but there are common themes...

<JeffH> 1) commonm pluggable interface to crypto/sec stuff

<JeffH> 2) concept of user identity being attached to browser state

<JeffH> 3) device ids and certs

<JeffH> could see web devels handling the latter if using JSON

<PHB> This is a standards proposal. A standard means making choices and having one way to do one thing unless there is a really good reason to do otherwise

<JeffH> dave crocker: distinction btwn devices and people; and people may have mult personas; but that is about user ident; but tghere is also service provider ident; might need to consider the latter more

<PHB> Time and again we have had framework proposals that end up giving six different ways to do username password, ten different ways to use public key and so on.

<PHB> Standards are choices, a framework or pluggable API is kicking the can down the road to later on

<JeffH> dirk balfanz (sp?): thinks there's lowerhanging fruit here; this fancy magic fairy dust may be distracting us; perhaps we should focus on some lower-key aspects of this stuff

<JeffH> nico: crypto is impl'd in JS, so some want to just give it to them, but if done in pure JS, it precludes interfacing with the rest of the browser enviornment -- no integration

<JeffH> nico: we shud resist the temptation to give them crypto api

<JeffH> ===================================

<JeffH> new session: 15:15-16:30 Position of Browsers

<JeffH> new scribe ?? (please?)

<JeffH> hhalpin: ok, so are the browsers listening?

<JeffH> mike hanson: here w/Ben Adida & Dan Mills

<JeffH> Firefox folk

<tyler> Mike Hanson of Mozilla presenting....

<tlr> ScribeNick: tyler

<JeffH> i off the hook ?

<tlr> JefH, we'll put you on the hook again :)

Reviewing past and current browser identity support...

<tlr> also, thanks!

thanks JeffH and tyler!

<JeffH> thx tyler

User logs into their browser, primarily to support sync

np, JeffH

How to present consent UX when giving data / permissions to a Web page is an open problem.

Account Manager enables sites to declare how they manage sessions.

Browser support for non-federated session management was not popular with sites.

Also had problems finding meaningful way for browser to participate in federated login such as OpenID.

Still think browser should help more with managing session state.

We can do better than quit the browser to end the session.

Proposing an API that lets a page tell the browser who the user is logged in as. Browser will provide a display of this info.

Tricky for non-HTML resources.

Trying to be smart about tying this to cookies.

We believe the internet is consolidating on email address as user identifier.

Strawman: signed attributes in the browser, such as email addresses

Crypto lets the browser cache attribute assertions and still have RPs trust them.

RPs can declare interest in receiving such assertions.

window.onVerifiedEmail(...)

Identity Provider adds identifiers to the browser via another API: navigator.id.registerVerifiedEmail(...)

We're at the UX testing stage.

Dirk Pranke from Google now presenting...

"Identity in the Browser: Easy Wins and Guiding Principles"

Is there a role for the browser in identity on the Web?

Browser is typically there, unless there's an app, which I'll call a browser.

Browser is necessarily trusted.

But, the browsers are all different.

That might limit how much can be done.

Chrome: Speed, Simplicity, Security

also stability

Speed implies making identity management UI faster

Simplicity implies helping the user understand, so a simple mental model.

Was Infocard too complex?

We're working on profiles now.

Keep work and personal separate

What happens when worlds collide, funny YouTube link from coworker.

So we're trying for a simpler scenario.

How do we make login/logout faster for couch passing of a laptop.

Security implies make things safer

that was fuzzy

Easy wins: better profiles, password managers

autocomplete off is a bad idea

better password manager === better security

easy than figuring out federated identity across the globe

Data portability is another easy win

Interoperable sync across apps

<maryhodder> why is it fluffy to have good usability and to serve lots of user's interests (not just the default user that is like an engineer) ?

Better anonymity and privacy

Tor is cool

<PhilHunt> What happens if a web site implements random multi-factor authentication? Need something more than scanning HTML code

Reduce the set of web fingerprinting tools.

Craig Wittenberg from Microsoft

"Consumer Third Party Authentication"

will present analysis of authentication and authorization problems

<josephboyle> Why don't OSes allow you to launch a browser window that runs "as" another OS user account? This might be much faster than "fast user switching" which still swaps out all of the current user's virtual memory. Plus running "as" guest or nobody would implement anonymous browsing.

second part is short term proposals from IE team

NewGroup technology enables passing of identity info.

The question is what UX to we put on it.

There are two parts to the problem:

1. How do we login?

2: How do we do 3 party login.

There's an impression that 3 party login is better than 2. I dispute that.

Leaving aside UX for rest of preso

Three things part of the login experience:

Brand, want that to be in front of user and controlled by RP

NASCAR takes away from the RP's brand

3 party involves more systems, so more failures

Can't create an SLA if relying on unknown third party.

That was all the second part: Reliability

Third part is Privacy

Talking with ACLU about problems and how technology can help

IDP can track where you login

3 party login enables tracking

2 party login has fewer privacy problems

Solutions are a pyramid: Trust Framework > Shared Symmetric Strong Secrets > Privacy Friendly Login Certificates

Don't have users create user ids or passwords.

Brands style certificates are cool

as in Stefan Brands

"Practical Next Steps"

Propose standard annotations for login forms

Bubble failures up to HTTP layer instead of everything over 200 OK

Propose trusted popups with security decorations

Propose crypto primitives in the browser

David Singer from Apple presenting...

Most users have multiple identities

Less of a problem if one is stolen.

Some passwords are protected better than others.

One identity service is a chokehold on what users can do.

Causes reliability problems.

Sites like to own their login for that reason

Only the W3C uses HTTP auth

Everybody else wants to control the UI

So browser doesn't know whats going on

Can't help prevent phishing

Browser could do something useful if it knew what was going on

Asking the user if its OK to accept an expired certificate is not a good way to involve the user.

Need to ask higher level questions

Esteban Velazquez from Opera presenting...

"Improving password managers and multidevice synchronization"

Three things. First is almost done, others are future plans

The future work is also about involving the browser more, like previous talk

First is synchronization across devices

syncing passwords like others

not useful to have passwords on only one device.

Users have many devices

but it's also scary to sync

Need to standardize what gets stored/synced

Need a common model for passwords, so that we can sync across browsers

Moving on to future work

browser can't identify credential text fields

<bblfish> the best way to deal with broken certificates, is for the server to accept the certificate even if broken and then to provide feedback at the http layer by returning a nice page explaining the error. That is what https://bblfish.net:8443/test/WebId does for WebIDs

can't identify what to *not* remember

browser doesn't know how the fields are used to login to a website

Third thing is managing identity information

changing password is different everywhere

<bblfish> ( not saying that the test page above is an excellent UI. Just a proof of concept)

Does the page have two passwords or a password confirmation?

Browser can't change passwords for you

Want metadata to help the browser

Q&A

Q: In 3 party login can't prevent tracking? Not true

Not with current solutions, but maybe other designs

<karen> Questioner is Francisco Corella, Pomcor

sketches a possible design

sketching another with browser keypair generation

Zero knowledge proofs can help with collusion between IDP and RP

A: Thanks, I recognize your feedback on my paper and I intend to get back to you.

I was saying current tech does not support this

<karen> A= response from Craig Wittenberg, Microsoft

We can do better when we design from scratch

ZK proofs might help

<karen> David Singer, Apple responds

Q: Users are freaked by correlation between logins

by David Singer

Q: Philip Hallam Baker

user can do password management without involvement of sites

<JeffH> just fyi: I have to go scorekeep at a Little League game here in a few minutes..... will see most all of y'all tomorrow....

syncing passwords in the cloud might lead to SAML

Comment from Mike Hanson

We don't know what to do with identifiers input by user

Figuring out that a password change just happened is really hard

Good password management presupposes good metadata

PHB: once we get millions of credentials in the cloud via password management we can turn them into IDPs

<karen> ack Mike Jones

<bblfish> of course I'd argue that one can do a lot more with SSL than is realised by using WebID. Turn TLS into a a web of trust is just a bit of coding away http://bit.ly/m1oG7M

adrian of IE wants metadata in forms

HTML next wiki also encouraging more metadata on forms, also the IE team

<tlr> http://www.w3.org/wiki/HTML/next#Enhancing_Authentication_Forms

On first party vs third party: merchants say they aren't experts and aren't doing login right.

Banks do very sophisticated login analysis

risk based analysis

So there's a lot of value add for a merchant to leverage the better logins

<tantek> frankly, I'd like to see something like <input type="identity-url"> added in addition to HTML5's current <input type="url">

A: large IDP can still track

<tantek> regarding more metadata in forms

MH: In our proposal browser can assert identity to a site "for a while" helps with tracking.

Q: I want to be able to annotate the kind of secrecy I require on each of my passwords.

I want smack

Q: You mean multi-level security

MH: It's only useful if some other software can get those labels

Q: What's smack

simplified manatory access control SMAC

can't hear the question

<karen> http://en.wikipedia.org/wiki/Simplified_Mandatory_Access_Control_Kernel

Karen, are you at the other end of the room?

Q: Have we thought about a centralized vault of authentications in the browser?

A: Dirk says we've thought about sign into the browser, like sign into the OS

Ben Laurie's Nigori

syncs data across providers so no single one has the data

haven't gone very far with it yet

MH: we've got some addons that explore territory like that

Craig: There's cred vault in Windows

has extensible schemas and some stuff that isn't well known

Session ends

- DRAFT -

SV_MEETING_TITLE

24 May 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output