<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Title" content="">
<meta name="Keywords" content="">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:Calibri;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:Calibri;
color:windowtext;}
span.msoIns
{mso-style-type:export-only;
mso-style-name:"";
text-decoration:underline;
color:teal;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:Calibri;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body bgcolor="white" lang="EN-US" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Big thanks to Annabelle for being the scribe. Please report any errors or omissions.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">/Dick<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Attendees:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> George Fletcher, AoL (<a href="mailto:george.fletcher@teamaol.com">george.fletcher@teamaol.com</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Brad Hill, Facebook (<a href="mailto:hillbrad@fb.com">hillbrad@fb.com</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Amir Naor, Facebook (<a href="mailto:amirn@fb.com">amirn@fb.com</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Michael MacLaughlin, Microsoft (<a href="mailto:michmcla@microsoft.com">michmcla@microsoft.com</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Marius Scurtescu, Google (<a href="mailto:mscurtescu@google.com">mscurtescu@google.com</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Jeroen Kemperman, Google (<a href="mailto:kemperman@google.com">kemperman@google.com</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Ilona Gaweda, Google (<a href="mailto:jelonka@google.com">jelonka@google.com</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam Dawes, Google (<a href="mailto:adawes@google.com">adawes@google.com</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Andrew Nash, Confyrm (<a href="mailto:andrew@confyrm.com">andrew@confyrm.com</a>)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil Hunt, Oracle (<a href="mailto:phil.hunt@oracle.com)">phil.hunt@oracle.com)</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick Hardt, Amazon (<a href="mailto:dick@amazon.com)">dick@amazon.com)</a><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Annabelle Richard Backman, Amazon (<a href="mailto:richanna@amazon.com)">richanna@amazon.com)</a>
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Action Items:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Survey members to decide whether RSA or Enigma is a better time<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> for our next F2F.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Notes:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Primer on Security Event Token Specification - Phil Hunt<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil presented the format and attributes for Security Event Tokens as<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> defined in the current draft of the spec. Briefly reviewed the on-going<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> discussion over the format for identifying event types and event<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> metadata, and the risk of existing JWT implementations mistaking a SET<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> for an authentication-granting JWT.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> SET "sub" Attribute<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Lengthy discussion around the semantics of the "sub" attribute in SETs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Subject may be different for sub-events, audiences. Subject may need to<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> be something in the RP's space, not the issuer's. Subject is not always<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> user, could be session, token, etc.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> George, Dick: RISC events for IoT use cases do not necessarily involve a<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> user.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> George: OpenID subjects are relative to issuer; could embed the ID token<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> in the event metadata for OpenID Logout events.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Registration Flow - Adam Dawes<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Discussed the process for an RP notifying an IdP that it wants to<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> receive messages for an identifier. Agreed to use the words "subscribe"<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> and "unsubscribe" instead of "register" and "deregister."<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Need for explicit subscription<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Brad: Instead of sending explicit signals, RPs could annotate password<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> reset emails, and mail provider could block them if the account is known<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> to be compromised.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: "Known to be compromised" state doesn't exist. Google would lock<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> the account, so no point in blocking email.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Google may not know yet; Amazon might detect compromise first.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Consensus that explicit subscription and signaling between RP and IdP<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> has value.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Account quality info<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Would like to receive account quality info from IdP.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Outside the scope of RISC; can be done over existing OAuth 2.0<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> mechanisms.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Subscription mechanisms<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> George: Shouldn't require OAuth 2.0 dance for subscription, RPs will<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> have UX concerns.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: RISC can be covered by TOS, do not need explicit consent flow.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Should not mix security events with data exchange, need a wall around<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> RISC data, limiting usage to security systems.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil: RP can send subscribe event to IdP in back channel.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Google will allow back channel subscription for some parties,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> requiring signed contracts, OIX membership, or some other mechanism.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Other parties can subscribe via OAuth 2.0.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Backfilling subscriptions<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: No batch support needed. Use the normal subscription mechanism,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> one call per subscription to be backfilled. (General consensus)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Unsubscribing / Events vs. commands<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Use cases: User may change email at RP, may opt out of sending<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> events to RP at the IdP.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Difference between RP signaling to IdP "user changed email" and<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> "unsubscribe from identifier"; delay before latter event is sent.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil: Some events are cause/effect based, some are analytics.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Have a control plane for commands (e.g. "unsubscribe me") and data<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> plane for events (e.g. account state changes).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> IdP discovery<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Discovery of authoritative entity for identifier is separate<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> discussion.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Google not prioritizing vanity domains, not heavily concerned<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> about that use case.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> George: Need to consider how to handle subscribe events for identifiers<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> you don't control; saying "I don't own this" leaks information about<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> accounts.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Since back channel subscriptions are limited to trusted parties,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> maybe this is acceptable.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Authoritative entity can change, e.g. Acme.com moving from Google<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> to Office 365.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Event propagation, RISC network topology<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil: Do event receivers propagate those events to their subscribers?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: No, receiver should process the event, and may send out separate<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> events based on state changes it makes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil: Is there demand for indicating the reason for a state change?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Amazon explicitly does not want that; Google shouldn't say they<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> took action because Amazon told them something.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Signal from non-authoritative sources<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Brad: What about when the authoritative entity doesn't support RISC?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Could be value in subscribing to events from a non-authoritative source.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Brad: Shouldn't assume that subscription only happens with the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> authoritative source for identifier.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Facebook RPs can subscribe to Facebook's events over OAuth 2.0;<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Amazon and Facebook could sign contracts and attempt subscriptions for<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> new accounts based on email hashes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> SET transport mechanism - Marius Scurtescu<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Presented proposal for SET transport mechanism: JWT in HTTP POST, one<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> event per request.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Marius: Recipient MUST parse and validate JWT before responding, to<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> guarantee delivery.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil: Guaranteed delivery not always necessary; could change MUST to SHOULD.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> George: Need to think about retry mechanisms, avoid overwhelming recipient.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> George: Reuse error nomenclature from OAuth 2.0, align our response<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> field names with theirs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Subscriber configuration over SCIM - Marius Scurtescu<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil: Reusing SCIM eases IESG concerns about yet another protocol.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Is a configuration API necessary right now? Could do this through<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> portals.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil: Need API for scalability for multi-tenant systems.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Could put publisher and subscriber metadata in a .well-known.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil: Uncomfortable with making subscriber metadata publicly accessible.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> George: Endpoints are public regardless, so risk exists either way.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam/George/Dick: SCIM seems too heavy for establishing pub/sub<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> relationship.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Phil: Maybe true for RISC, but not for other SET use cases.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Discovery, encryption support<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Can we piggyback on OIDC's key discovery mechanism, can subscriber<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> derive everything from pub's issuer? (e.g. via a .well-known)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Marius: Publisher needs subscriber's keys to encrypt SETs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Do we need to support encryption if we're using TLS?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: We should require TLS.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Annabelle: TLS isn't always end-to-end.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Michael: We would like to encrypt events even if transport is encrypted.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> State sharing at subscription time<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Debate over whether IdP should publish anything to RP when the RP<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> subscribes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Annabelle: Think of events as reporting current account state, rather<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> than reporting change of state.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: IdP should publish event indicating current state of account if<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> account is in some invalid state.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> George: We only want to publish binary status, e.g. "valid" and<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> "invalid" even though internal model may have many states.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> SMTP transport mechanism<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Did we agree on whether to standardize transport over SMTP?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Introduces additional attack vectors, challenges.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: For standard, let's just focus on HTTP. (consensus)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Meta: Next face-to-face meeting<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Dick: Need to schedule next face-to-face soon to maintain momentum<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Adam: Will follow up on list to decide whether meeting around RSA or<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Enigma is better.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Meta: Call schedule<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> Discussed, will keep current call schedule and arrange additional calls<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> on an ad hoc basis.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> -<o:p></o:p></span></p>
</div>
</body>
</html>