Content-Type: multipart/signed;
 boundary="Apple-Mail=_91E446E5-80FE-4509-9021-964CF3CB83FE";
 protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <ldvsih0yvpu.fsf@sarnath.mit.edu>
Date: Sun, 30 Nov 2014 21:15:21 -0500
Message-Id: <1E83C7F4-BD75-4038-8FD3-E374A02713AF@mit.edu>
References: <ldvsih0yvpu.fsf@sarnath.mit.edu>
To: Tom Yu <tlyu@mit.edu>
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/p1svZsAHi_CYT37FqVk4-rB3I44
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] [internet-drafts@ietf.org] New Version Notification
 for draft-yu-oauth-token-translation-01.txt
Precedence: list


--Apple-Mail=_91E446E5-80FE-4509-9021-964CF3CB83FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Tom,

I think this is interesting and important work as it could help more =
directly bridge the gap between Kerberos deployments (more common in =
enterprise/LAN environments) and the OAuth/web/mobile world.=20

When you get down to it, there are really two things going on here: =
mapping Kerberos ticket claims to JWT claims (and vice versa), and the =
act of actually translating a ticket into an OAuth token. Perhaps these =
should be separated more cleanly? I can very easily picture a service =
that takes in Kerberos tickets and spits out unstructured tokens (or at =
least tokens without the same claims baked in). This could be specified =
as an extension of the OAuth Assertions framework, mirroring the JWT and =
SAML assertions, and could pretty easily be picked up as a WG document =
if people wanted it.=20

In addition to that (but ultimately separate from it, whether it=92s in =
the same document or not), a mechanism for expressing the set of =
information that=92s inside of the Kerberos ticket using the JOSE family =
of specs still makes sense to have. Much of what=92s in JWT=92s claim =
set was influenced by SAML and (to a lesser extent) X.509, so it seems =
useful to have a similar Kerberos-to-JWT translation process, especially =
since Kerberos has a few fields that aren=92t covered by the current JWT =
claim set and could be found useful by applications. Better to line up =
with an existing protocol in this case, in my opinion.

 =97 Justin

On Nov 30, 2014, at 9:01 PM, Tom Yu <tlyu@mit.edu> wrote:

> Added more technical details and examples.
>=20
> <New Version Notification for =
draft-yu-oauth-token-translation-01_txt.eml>______________________________=
_________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


--Apple-Mail=_91E446E5-80FE-4509-9021-964CF3CB83FE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQEcBAEBAgAGBQJUe885AAoJEDPAngkbd+w9BwkIAKaigQfQf7Rcm5XF3+6ZsgEE
kLXzQ/lyDEkGVaaJdOoo0DtHEmpjdEDPkjBDj/wDMBp7o3eCT953VXkcEnQ9nf+8
soxsbdV196h3rfLkc65exbFOSvIaSBmujl+7cXNnczyVLKfW1tU5VZKYFo7AKUNL
jQ+OwKLcR9z8mFffCAjOq/mAeToVv9OaOvIrZXSkxNEk4BjTeqhxiX6D6TZ+F9QJ
jn7hhk5/3tJXjYzlKQnEeja6UqV3CCAaW0g/LMO1Q+Nv+tchHy6bPwMVDZWtzcLW
4XSmkz7ZRxXXOAvRewzCD38O5uJze5qHVRF4bSjRHAjDjYE0BoFYM2mdczKiagw=
=bh0C
-----END PGP SIGNATURE-----

--Apple-Mail=_91E446E5-80FE-4509-9021-964CF3CB83FE--