Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C8E21F8611 for ; Wed, 16 Jan 2013 11:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljkowoLFBsaE for ; Wed, 16 Jan 2013 11:52:50 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5974B21F860A for ; Wed, 16 Jan 2013 11:52:50 -0800 (PST) Received: from BL2FFO11FD001.protection.gbl (10.173.161.203) by BL2FFO11HUB025.protection.gbl (10.173.161.49) with Microsoft SMTP Server (TLS) id 15.0.596.13; Wed, 16 Jan 2013 19:52:37 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Wed, 16 Jan 2013 19:52:37 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.202]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Wed, 16 Jan 2013 19:51:58 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: Principal -> Subject in Assertions spec? Thread-Index: Ac30IvFc/O0zg4CgRnm4qoarZkYplg== Date: Wed, 16 Jan 2013 19:51:57 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394366A4AFE4@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394366A4AFE4TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(5343655001)(47446002)(5343635001)(54316002)(49866001)(46102001)(56776001)(50986001)(16406001)(16236675001)(55846006)(47976001)(47736001)(4396001)(512954001)(77982001)(54356001)(59766001)(53806001)(76482001)(56816002)(15202345001)(33656001)(74662001)(74502001)(44976002)(51856001)(31966008)(79102001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB025; H:TK5EX14MLTC102.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07283408BE Subject: [OAUTH-WG] Principal -> Subject in Assertions spec? X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jan 2013 19:52:52 -0000 --_000_4E1F6AAD24975D4BA5B168042967394366A4AFE4TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In writing the proposed interoperability text for the Assertions specificat= ion, I noticed that the Assertions spec uses the term "Principal" to refer = to the subject of the assertion, whereas both the SAML and JWT profiles use= the term "Subject" for this same concept. I propose that at the same time= we add the Interoperability statement, we also change the uses of the term= "Principal" to "Subject" in the assertions spec so that it's terminology u= sage is more consistent with the two profile specs using it. Thoughts? -- Mike --_000_4E1F6AAD24975D4BA5B168042967394366A4AFE4TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In writing the proposed interoperability text for th= e Assertions specification, I noticed that the Assertions spec uses the ter= m “Principal” to refer to the subject of the assertion, whereas= both the SAML and JWT profiles use the term “Subject” for this same concept.  I propose that at the same time we add the In= teroperability statement, we also change the uses of the term “Princi= pal” to “Subject” in the assertions spec so that it’= ;s terminology usage is more consistent with the two profile specs using it.

 

Thoughts?

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

--_000_4E1F6AAD24975D4BA5B168042967394366A4AFE4TK5EX14MBXC284r_--