Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt

Anil Saldhana <Anil.Saldhana@redhat.com> Thu, 03 April 2014 16:38 UTC

Return-Path: <Anil.Saldhana@redhat.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729241A0264 for <oauth@ietfa.amsl.com>; Thu, 3 Apr 2014 09:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KITdaPU8vBM4 for <oauth@ietfa.amsl.com>; Thu, 3 Apr 2014 09:37:57 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 8753B1A021B for <oauth@ietf.org>; Thu, 3 Apr 2014 09:37:57 -0700 (PDT)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s33GbrAl007736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Thu, 3 Apr 2014 12:37:53 -0400
Received: from [10.10.61.189] (vpn-61-189.rdu2.redhat.com [10.10.61.189]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s33GbpjN015282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <oauth@ietf.org>; Thu, 3 Apr 2014 12:37:52 -0400
Message-ID: <533D8E5F.8000600@redhat.com>
Date: Thu, 03 Apr 2014 11:37:51 -0500
From: Anil Saldhana <Anil.Saldhana@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
MIME-Version: 1.0
To: oauth@ietf.org
References: <20140403083747.31162.58961.idtracker@ietfa.amsl.com> <1396541184.357.YahooMailNeo@web125601.mail.ne1.yahoo.com> <533D8CA3.6070005@oracle.com>
In-Reply-To: <533D8CA3.6070005@oracle.com>
Content-Type: multipart/alternative; boundary="------------060002030101000003040206"
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/8TMO-B0HEiC58CDSGm2B6n5Ixp0
Subject: Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-pop-architecture-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Apr 2014 16:38:03 -0000

Prateek,
   why not just use "proof"?

draft-hunt-oauth-proof-architecture-00.txt

Is that allowed by IETF?


Regards,
Anil

On 04/03/2014 11:30 AM, Prateek Mishra wrote:
> "key confirmed" or "key confirmation" is another term that is widely 
> used for these use-cases
>> I really *like* the name "proof of possession", but I think the 
>> acronym PoP is going to be confused with POP. HOTK has the advantage 
>> of not being a homonym for aything else.  What about "Possession Proof"?
>> -bill
>>
>>
>> --------------------------------
>> William J. Mills
>> "Paranoid" MUX Yahoo!
>>
>> On Thursday, April 3, 2014 1:38 AM, "internet-drafts@ietf.org" 
>> <internet-drafts@ietf.org> wrote:
>>
>> A new version of I-D, draft-hunt-oauth-pop-architecture-00.txt
>> has been successfully submitted by Hannes Tschofenig and posted to the
>> IETF repository.
>>
>> Name:        draft-hunt-oauth-pop-architecture
>> Revision:    00
>> Title:        OAuth 2.0 Proof-of-Possession (PoP) Security Architecture
>> Document date:    2014-04-03
>> Group:        Individual Submission
>> Pages:        21
>> URL: 
>> http://www.ietf.org/internet-drafts/draft-hunt-oauth-pop-architecture-00.txt
>> Status: 
>> https://datatracker.ietf.org/doc/draft-hunt-oauth-pop-architecture/
>> Htmlized: http://tools.ietf.org/html/draft-hunt-oauth-pop-architecture-00
>>
>>
>> Abstract:
>>   The OAuth 2.0 bearer token specification, as defined in RFC 6750,
>>   allows any party in possession of a bearer token (a "bearer") to get
>>   access to the associated resources (without demonstrating possession
>>   of a cryptographic key).  To prevent misuse, bearer tokens must to be
>>   protected from disclosure in transit and at rest.
>>
>>   Some scenarios demand additional security protection whereby a client
>>   needs to demonstrate possession of cryptographic keying material when
>>   accessing a protected resource.  This document motivates the
>>   development of the OAuth 2.0 proof-of-possession security mechanism.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of 
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>