html source

<p>Most frequent issues in order of frequency</p>
<ol>
	<li>Simpler protocol for simpler use-cases</li>
	<li>IDP whitelist/certification</li>
	<li>Non-browser apps</li>
	<li>Email as identifier</li>
	<li>Additional attributes (Billing/Address/sex/gender/location/basic-reputation)</li>
	<li>Improve Nascar UI with central discovery mechanism</li>
	<li>Best practices for sign-out, and quick switch between identities</li>
</ol>
<hr />
<p>There appeared to be presenters on 1, 2, 4, and 7 for Tuesday.</p>
<ol>
	<li>
		<p><strong>Simpler protocol for simpler use-cases</strong></p>
		<ul>
			<li>Use Case 1: Single IDP (internal, Facebook, Twitter, LinkedIn, PayPal, etc.)</li>
			<li>Use Case 2: Nascar UI for whitelist of IDPs</li>
			<li>Use Case 3: Nascar UI for whitelist of IDPs with Email as identifier</li>
		</ul>
		<p>Requests:</p>
		<ul>
			<li>must do oauth+openid</li>
			<li>simpler libraries for those use-cases</li>
			<li>libraries with RPX like functionality</li>
			<li>smaller libraries</li>
			<li>libraries that can be linked to a continuous build</li>
			<li>avoid realm complications for simpler use-cases</li>
			<li>leverage manual key registration for simpler use-cases</li>
			<li>simpler use-case should be sufficient for Twitter &amp; FB to use so there is a single protocol</li>
		</ul>
	</li>
	<li>
		<p><strong>IDP whitelist/certification</strong></p>
		<ul>
			<li>libraries should have hardcoded discovery information for big IDPs</li>
			<li>best practices for liability</li>
			<li>certification of IDPs for: 
				<ul>
					<li>uptime</li>
					<li>what email they can provide</li>
					<li>consistency in functionality</li>
					<li>consistency in UI</li>
				</ul>
			</li>
		</ul>
	</li>
	<li>
		<p><strong>Non-browser apps</strong></p>
		<ul>
			<li>Best practices for doing OAuth on different platforms</li>
		</ul>
	</li>
	<li>
		<p><strong>Email as identifier</strong></p>
		<ul>
			<li>For IDP discovery from Email, should RPs use a whitelist or webfinger?</li>
			<li>How does RP know which IDP can assert addresses in a particular domain, i.e. a Google Account for an @yahoo.com address with a weak password should not be usable to login to an RP who directly supports Yahoo as an IDP</li>
			<li>Best practices to use OpenID for email validation</li>
		</ul>
	</li>
	<li>
		<p><strong>Additional attributes</strong> (Billing/Address/CC#/sex/gender/location/basic-reputation)</p>
		<p>Best practices, especially for reputation data?</p>
	</li>
	<li>
		<p><strong>Improve Nascar UI with central discovery mechanism</strong></p>
		<ul>
			<li>Meebo presentation</li>
			<li>Older PDS/CDS proposals</li>
		</ul>
	</li>
	<li>
		<p><strong>Best practices for sign-out, and quick switch between identities</strong></p>
		<ul>
			<li>Is sign-out an OS problem or browser problem?</li>
			<li>How should browsers and installed-apps deal with a single human two 2+ identities they want to use simultaneously (work + personal)</li>
		</ul>
	</li>
</ol>