date:20140406

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

2014-04-06 Thread Anthony Nadalin

I have to agree with Phil on this as there are already spec out there that use 
HoK and PoP , either of these work but prefer HoK as folks get confused with 
PoP as we have seen this within our company already

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Mike Jones
Sent: Thursday, April 3, 2014 11:32 AM
To: John Bradley; Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-pop-architecture-00.txt

I agree with what John wrote below.  Besides, PoP is more natural to say than 
HoK and certainly more natural to say than HOTK.  I'd like us to stay with the 
term Proof-of-Possession (PoP).

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of John Bradley
Sent: Thursday, April 03, 2014 11:10 AM
To: Phil Hunt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] New Version Notification for 
draft-hunt-oauth-pop-architecture-00.txt

Some people and specs associate holder of key with asymmetric keys.  Proof of 
possession is thought to be a broader category including symmetric and key 
agreement eg http://tools.ietf.org/html/rfc2875.

NIST defines the term PoP Protocol 
http://fismapedia.org/index.php?title=Term:Proof_of_Possession_Protocol

In SAML the saml:SubjectConfirmation method  is called 
urn:oasis:names:tc:SAML:2.0:cm:holder-of-key

In WS* the term proof of possession is more common.

So I think for this document as an overview "Proof of Possession (PoP) 
Architecture" is fine.

John B.

On Apr 3, 2014, at 12:41 PM, Phil Hunt 
mailto:phil.h...@oracle.com>> wrote:

What was wrong with HOK?

Aside: Why was "the" so important in HOTK?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

On Apr 3, 2014, at 9:37 AM, Anil Saldhana 
mailto:anil.saldh...@redhat.com>> wrote:

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-dra...@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

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

2014-04-06 Thread Mike Jones

OpenID Connect defines how it happens for OpenID Connect.  Other dynamic OAuth 
use cases still definitely need this.

From: Phil Hunt [mailto:phil.h...@oracle.com]
Sent: Sunday, April 06, 2014 10:49 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration 
Documents

So in other words, OpenID Connect defines (or should define) how this happens.

There is no need for the Dyn Reg spec to clarify this right?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com

On Apr 6, 2014, at 10:44 AM, Mike Jones 
mailto:michael.jo...@microsoft.com>> wrote:

As a point of clarity, OpenID Connect does not mandate support for dynamic 
registration in all cases.  In static profiles with a pre-established set of 
identity providers, it isn't required.  It *is* required in the dynamic 
profile, in which clients can use identity providers that they have no 
pre-existing relationship with.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Sunday, April 06, 2014 12:59 AM
To: Bill Mills
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration 
Documents

I think it is at the discretion of the actual deployment whether clients may 
dynamically register or not (meaning they need to go through some oob 
mechanism). Protocols utilizing OAuth could make it part of their mandatory to 
implement features - in the same way OIDC does.

Best regards,
Torsten.
Am 06.04.2014 um 07:12 schrieb Bill Mills 
mailto:wmills_92...@yahoo.com>>:
To me the fundamental question of whether a client has to be registered in each 
place it is used is quite significant.  We don't address the problem and have 
not discussed it enough.

-bill
On Friday, April 4, 2014 11:39 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
Hi Bill,

which scalability problem are you referring to? As far as I remember there were 
issues around the management API but not the core protocol.

regards,
Torsten.

Am 04.04.2014 um 18:41 schrieb Bill Mills 
mailto:wmills_92...@yahoo.com>>:
Given the fundamental scalability problem we discussed in London do we really 
feel we're ready?
On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

Since we have to do the last call for these two documents together we
are setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

Ciao
Hannes & Derek

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

2014-04-06 Thread Phil Hunt

So in other words, OpenID Connect defines (or should define) how this happens.

There is no need for the Dyn Reg spec to clarify this right?

Phil

@independentid
www.independentid.com
phil.h...@oracle.com



On Apr 6, 2014, at 10:44 AM, Mike Jones  wrote:

> As a point of clarity, OpenID Connect does not mandate support for dynamic 
> registration in all cases.  In static profiles with a pre-established set of 
> identity providers, it isn’t required.  It *is* required in the dynamic 
> profile, in which clients can use identity providers that they have no 
> pre-existing relationship with.
>  
> -- Mike
>  
> From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
> Sent: Sunday, April 06, 2014 12:59 AM
> To: Bill Mills
> Cc: oauth@ietf.org
> Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client 
> Registration Documents
>  
> I think it is at the discretion of the actual deployment whether clients may 
> dynamically register or not (meaning they need to go through some oob 
> mechanism). Protocols utilizing OAuth could make it part of their mandatory 
> to implement features - in the same way OIDC does.
>  
> Best regards,
> Torsten.
> Am 06.04.2014 um 07:12 schrieb Bill Mills :
> 
> To me the fundamental question of whether a client has to be registered in 
> each place it is used is quite significant.  We don't address the problem and 
> have not discussed it enough.
>  
> -bill
> On Friday, April 4, 2014 11:39 PM, Torsten Lodderstedt 
>  wrote:
> Hi Bill,
>  
> which scalability problem are you referring to? As far as I remember there 
> were issues around the management API but not the core protocol.
>  
> regards,
> Torsten.
> 
> Am 04.04.2014 um 18:41 schrieb Bill Mills :
> 
> Given the fundamental scalability problem we discussed in London do we really 
> feel we're ready?
> On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig 
>  wrote:
> Hi all,
> 
> This is a Last Call for comments on the dynamic client registration
> documents:
> 
> * OAuth 2.0 Dynamic Client Registration Core Protocol
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
> 
> * OAuth 2.0 Dynamic Client Registration Metadata
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00
> 
> Since we have to do the last call for these two documents together we
> are setting the call for **3 weeks**.
> 
> Please have your comments in no later than April 25th.
> 
> Ciao
> Hannes & Derek
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>  
> 
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

2014-04-06 Thread Mike Jones

As a point of clarity, OpenID Connect does not mandate support for dynamic 
registration in all cases.  In static profiles with a pre-established set of 
identity providers, it isn’t required.  It *is* required in the dynamic 
profile, in which clients can use identity providers that they have no 
pre-existing relationship with.

-- Mike

From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Torsten Lodderstedt
Sent: Sunday, April 06, 2014 12:59 AM
To: Bill Mills
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration 
Documents

I think it is at the discretion of the actual deployment whether clients may 
dynamically register or not (meaning they need to go through some oob 
mechanism). Protocols utilizing OAuth could make it part of their mandatory to 
implement features - in the same way OIDC does.

Best regards,
Torsten.
Am 06.04.2014 um 07:12 schrieb Bill Mills 
mailto:wmills_92...@yahoo.com>>:
To me the fundamental question of whether a client has to be registered in each 
place it is used is quite significant.  We don't address the problem and have 
not discussed it enough.

-bill
On Friday, April 4, 2014 11:39 PM, Torsten Lodderstedt 
mailto:tors...@lodderstedt.net>> wrote:
Hi Bill,

which scalability problem are you referring to? As far as I remember there were 
issues around the management API but not the core protocol.

regards,
Torsten.

Am 04.04.2014 um 18:41 schrieb Bill Mills 
mailto:wmills_92...@yahoo.com>>:
Given the fundamental scalability problem we discussed in London do we really 
feel we're ready?
On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig 
mailto:hannes.tschofe...@gmx.net>> wrote:
Hi all,

This is a Last Call for comments on the dynamic client registration
documents:

* OAuth 2.0 Dynamic Client Registration Core Protocol
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16

* OAuth 2.0 Dynamic Client Registration Metadata
http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00

Since we have to do the last call for these two documents together we
are setting the call for **3 weeks**.

Please have your comments in no later than April 25th.

Ciao
Hannes & Derek

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

2014-04-06 Thread Phil Hunt

Hmm. I think this issue is self evident to the developer

If they have obtained a client id through developer registration (current 
typical oauth) they are good to go. 

IOW If you have a client id issued out of band you are good to go. 

Otherwise look for dyn reg or some other method. This likely happens where 
clients connect to apis and/or protocols deployed by many service providers  eg 
OIDC. An emerging example I heard at ietf london was interest in adapting oauth 
to non web protocols like smtp, imap, pop and even jabber. 

Phil

> On Apr 6, 2014, at 0:59, Torsten Lodderstedt  wrote:
> 
> I think it is at the discretion of the actual deployment whether clients may 
> dynamically register or not (meaning they need to go through some oob 
> mechanism). Protocols utilizing OAuth could make it part of their mandatory 
> to implement features - in the same way OIDC does.
> 
> Best regards,
> Torsten.
>> Am 06.04.2014 um 07:12 schrieb Bill Mills :
>> 
>> To me the fundamental question of whether a client has to be registered in 
>> each place it is used is quite significant.  We don't address the problem 
>> and have not discussed it enough.
>> 
>> -bill
>> On Friday, April 4, 2014 11:39 PM, Torsten Lodderstedt 
>>  wrote:
>> Hi Bill,
>> 
>> which scalability problem are you referring to? As far as I remember there 
>> were issues around the management API but not the core protocol.
>> 
>> regards,
>> Torsten.
>> 
>>> Am 04.04.2014 um 18:41 schrieb Bill Mills :
>>> 
>> 
>>> Given the fundamental scalability problem we discussed in London do we 
>>> really feel we're ready?
>>> On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig 
>>>  wrote:
>>> Hi all,
>>> 
>>> This is a Last Call for comments on the dynamic client registration
>>> documents:
>>> 
>>> * OAuth 2.0 Dynamic Client Registration Core Protocol
>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
>>> 
>>> * OAuth 2.0 Dynamic Client Registration Metadata
>>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00
>>> 
>>> Since we have to do the last call for these two documents together we
>>> are setting the call for **3 weeks**.
>>> 
>>> Please have your comments in no later than April 25th.
>>> 
>>> Ciao
>>> Hannes & Derek
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> 
>>> ___
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

2014-04-06 Thread Torsten Lodderstedt

I think it is at the discretion of the actual deployment whether clients may 
dynamically register or not (meaning they need to go through some oob 
mechanism). Protocols utilizing OAuth could make it part of their mandatory to 
implement features - in the same way OIDC does.

Best regards,
Torsten.
> Am 06.04.2014 um 07:12 schrieb Bill Mills :
> 
> To me the fundamental question of whether a client has to be registered in 
> each place it is used is quite significant.  We don't address the problem and 
> have not discussed it enough.
> 
> -bill
> On Friday, April 4, 2014 11:39 PM, Torsten Lodderstedt 
>  wrote:
> Hi Bill,
> 
> which scalability problem are you referring to? As far as I remember there 
> were issues around the management API but not the core protocol.
> 
> regards,
> Torsten.
> 
>> Am 04.04.2014 um 18:41 schrieb Bill Mills :
>> 
> 
>> Given the fundamental scalability problem we discussed in London do we 
>> really feel we're ready?
>> On Friday, April 4, 2014 3:07 AM, Hannes Tschofenig 
>>  wrote:
>> Hi all,
>> 
>> This is a Last Call for comments on the dynamic client registration
>> documents:
>> 
>> * OAuth 2.0 Dynamic Client Registration Core Protocol
>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-16
>> 
>> * OAuth 2.0 Dynamic Client Registration Metadata
>> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-metadata-00
>> 
>> Since we have to do the last call for these two documents together we
>> are setting the call for **3 weeks**.
>> 
>> Please have your comments in no later than April 25th.
>> 
>> Ciao
>> Hannes & Derek
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> ___
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

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

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

Re: [OAUTH-WG] Working Group Last Call on Dynamic Client Registration Documents

6 matches

Site Navigation

Mail list logo

Footer information