DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
 h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type;
 b=emhWhTdY+ydT9F73uLDbG1i+YRy3R7S0K+t/V7id9OICg5ABING8+MTlxut5OoP8WMPo+mX28h9WyNBk1luQK3pCqXRhblDJwF+xozUleGMdEuYwZyLfPH/y8j9J4HLVoTmdTgjj3qNOilhAi6KTCYusSM01prdMmxHX2607uU0=;
Message-ID: <1360009331.12021.YahooMailNeo@web31801.mail.mud.yahoo.com>
Date: Mon, 4 Feb 2013 12:22:11 -0800 (PST)
From: William Mills <wmills_92105@yahoo.com>
To: O Auth WG <oauth@ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="-368338466-1500808155-1360009331=:12021"
Subject: [OAUTH-WG] conf call follow up from  today
Precedence: list
Reply-To: William Mills <wmills_92105@yahoo.com>

---368338466-1500808155-1360009331=:12021
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

1) =A0I think that we need to focus on specific solutions, as I said on the=
 call, and solve the OAuth 1.0a/MAC use case. =A0There's significant instal=
led base of OAuth 1.0a and we need a path for those installations into OAut=
h 2.0. =A0I may well pursue MAC in the interim to do this, but a full HOK s=
olution woul work too.=0A=0A2) =A0I think the discussion we were having abo=
ut "which authenticator to use" falls squarely into the endpoint discovery =
discussion and we should put that energy into endpoint discovery as distinc=
t from HOK.=0A=0A3) =A0We haven't talked yet about how a client will be abl=
e to specify a token type if it wants a specific one. =A0OAuth 2 core will =
need to be extended to support this.=0A=0A4) =A0We should leave the key dis=
tribution/discovery mechanism either out of scope or define it explicitly p=
er HOK token type profile. =A0This will have to work with the extensions fo=
r #3 above.=0A=0A5) =A0I want to avoid the problem in OAuth 1.0a of having =
to support and accept every possible signing mode. =A0Being force to accept=
 PLAINTEXT sucks. =A0We need a way for the discovery endpoint to mandate a =
specific set of allowed signature methods.=0A=0ARegards,=0A=0A-bill=0A
---368338466-1500808155-1360009331=:12021
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:Co=
urier New, courier, monaco, monospace, sans-serif;font-size:12pt"><div>1) &=
nbsp;I think that we need to focus on specific solutions, as I said on the =
call, and solve the OAuth 1.0a/MAC use case. &nbsp;There's significant inst=
alled base of OAuth 1.0a and we need a path for those installations into OA=
uth 2.0. &nbsp;I may well pursue MAC in the interim to do this, but a full =
HOK solution woul work too.</div><div><br></div><div style=3D"color: rgb(0,=
 0, 0); font-size: 16px; font-family: 'Courier New', courier, monaco, monos=
pace, sans-serif; background-color: transparent; font-style: normal;">2) &n=
bsp;I think the discussion we were having about "which authenticator to use=
" falls squarely into the endpoint discovery discussion and we should put t=
hat energy into endpoint discovery as distinct from HOK.</div><div style=3D=
"color: rgb(0, 0, 0); font-size: 16px; font-family: 'Courier New',
 courier, monaco, monospace, sans-serif; background-color: transparent; fon=
t-style: normal;"><br></div><div style=3D"color: rgb(0, 0, 0); font-size: 1=
6px; font-family: 'Courier New', courier, monaco, monospace, sans-serif; ba=
ckground-color: transparent; font-style: normal;">3) &nbsp;We haven't talke=
d yet about how a client will be able to specify a token type if it wants a=
 specific one. &nbsp;OAuth 2 core will need to be extended to support this.=
</div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: 'Cou=
rier New', courier, monaco, monospace, sans-serif; background-color: transp=
arent; font-style: normal;"><br></div><div style=3D"color: rgb(0, 0, 0); fo=
nt-size: 16px; font-family: 'Courier New', courier, monaco, monospace, sans=
-serif; background-color: transparent; font-style: normal;">4) &nbsp;We sho=
uld leave the key distribution/discovery mechanism either out of scope or d=
efine it explicitly per HOK token type profile. &nbsp;This will have to
 work with the extensions for #3 above.</div><div style=3D"color: rgb(0, 0,=
 0); font-size: 16px; font-family: 'Courier New', courier, monaco, monospac=
e, sans-serif; background-color: transparent; font-style: normal;"><br></di=
v><div style=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: 'Courier=
 New', courier, monaco, monospace, sans-serif; background-color: transparen=
t; font-style: normal;">5) &nbsp;I want to avoid the problem in OAuth 1.0a =
of having to support and accept every possible signing mode. &nbsp;Being fo=
rce to accept PLAINTEXT sucks. &nbsp;We need a way for the discovery endpoi=
nt to mandate a specific set of allowed signature methods.</div><div style=
=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: 'Courier New', couri=
er, monaco, monospace, sans-serif; background-color: transparent; font-styl=
e: normal;"><br></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px; f=
ont-family: 'Courier New', courier, monaco, monospace, sans-serif;
 background-color: transparent; font-style: normal;">Regards,</div><div sty=
le=3D"color: rgb(0, 0, 0); font-size: 16px; font-family: 'Courier New', cou=
rier, monaco, monospace, sans-serif; background-color: transparent; font-st=
yle: normal;"><br></div><div style=3D"color: rgb(0, 0, 0); font-size: 16px;=
 font-family: 'Courier New', courier, monaco, monospace, sans-serif; backgr=
ound-color: transparent; font-style: normal;">-bill</div><div style=3D"colo=
r: rgb(0, 0, 0); font-size: 16px; font-family: 'Courier New', courier, mona=
co, monospace, sans-serif; background-color: transparent; font-style: norma=
l;"><br></div></div></body></html>
---368338466-1500808155-1360009331=:12021--