Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[Blaine Cook]

On 12 April 2012 17:51, Mike Jones  wrote:

> Thanks for asking these questions Hannes.  I'll first provide a brief
> feature comparison of Simple Web Discovery and WebFinger and then answer
> your questions.
>
> FEATURE COMPARISON
>
> RESULT GRANULARITY AND PRIVACY CHARACTERISTICS:  SWD returns the resource
> location(s) for a specific resource for a specific principal.  WebFinger
> returns all resources for the principal.  The example at
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2"Retrieving
>  a Person's Contact Information" is telling.  The WebFinger
> usage model seems to be "I'll get everything about you and then fish
> through it to decide what to do with it."  The protocol assumption that all
> WebFinger information must be public is also built into the protocol where
> the CORS response header "Access-Control-Allow-Origin: *" is mandated, per
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7.
>  The privacy characteristics of these approaches are very different.  (It's
> these very same privacy characteristics that led sysadmins to nearly
> ubiquitously disabling the fingerd service!)  Particularly for the OAuth
> use cases, narrow, scoped, and potentially permissioned responses seem
> preferable.
>

This is absolutely false.

SWD provides no privacy whatsoever. SWD makes it somewhat harder to crawl
large numbers of profiles, but it does not incorporate any real security,
and any attempt to suggest that it does is misleading and deceptive.

Webfinger, like any good HTTP service, is designed to allow access control
using appropriate means. That access control should not be *bound* to the
protocol, in the same way that HTTP does not have any REQUIRED access
control mechanisms, since doing so would severely restrict future usage of
a core protocol.

FUD has no place in a discussion of the technical and social merits of a
protocol.

For what it's worth, my intent with webfinger *from day one, nearly four
years ago*, has been to provide permissioned profile data *using EXISTING*
(or new, where appropriate or necessary, based on *running code and
deployment EXPERIENCE*) access control mechanisms for profile data.

The idea that there is ONE view of the data is patently false. For example,
depending on who is requesting my profile data, I might return different
contact telephone numbers, and this behaviour is completely feasible using
webfinger.


> DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY:  WebFinger is
> built on a "document model", where a single document is returned that
> contains multiple resources for a principal.  SWD is built on an "API
> model", where the location(s) of a particular resource for a principal are
> returned.  The problem with the document model is that different parties or
> services may be authoritative for different resources for a given
> principal, and yet all need the rights to edit the resulting document.
>  This hurts deployability, because document edits then need to be
> coordinated among parties that may have different rights and
> responsibilities, and may have negative security implications as well.
>  (Just because I can change your avatar doesn't mean that I should be able
> to change your mail server.)
>

WS-* was built on an API model, and that worked out very well.

APIs and documents on the web are the same thing; how you represent them
behind the scenes is up to you, and that's been a core principle of the web
since shortly after its inception. Suggesting otherwise profoundly
misunderstands how implementation of web services happens.

SWD says nothing of how to update profile data, so the security concerns
here are a total red herring.


> REDIRECT FUNCTIONALITY AND DEPLOYABILTY:  SWD includes the ability to
> redirect some or all SWD requests to another location (possibly depending
> upon the specific resource and principal parameters).  Deployers hosting
> numerous sites for others told the SWD authors that this functionality is
> critical for deployability, as it means that the SWD server for a domain
> can live in a location outside the domain.  WebFinger is lacking this
> functionality.  Given that OAuth is likely to be used in hosted
> environments, this functionality seems pretty important.
>

Umm, I'm not even sure what to say to this. host-meta is a static file that
points to a profile server (generally expected to be a dynamic "API"
server) that can be hosted on any domain.

The fact that you're suggesting that this core piece of webfinger
functionality is *missing* seriously undermines my belief that you're
acting in good faith, Mike.


> NUMBER OF ROUND TRIPS:  WebFinger discoveries for user information
> normally require both a host-meta query to retrieve the template and then a
> second query to retrieve the user's information.  This functionality is
> achieved in a single SWD query.
>

... at the cost of greater client complexity. A webfinger lookup may be
implemented with the foll

Re: [OAUTH-WG] WGLC on Assertion Drafts

[Brian Campbell]

Thanks Justin, a couple comments/questions are inline...

On Thu, Apr 5, 2012 at 10:53 AM, Justin Richer  wrote:
>
> http://tools.ietf.org/html/draft-ietf-oauth-assertions-01
>
>
> Section 7's second portion about a client including multiple credentials
> types seems buried down here in the Error Responses section for something
> this fundamental.

Yeah, I can see that. Although the restriction on multiple client
authentication methods is actually inherited from core OAuth (last
sentence in http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-2.3)
so maybe there shouldn't even normative language about it in this doc?

> It also conflates discussion of selection of this client
> authorization type in here, where it ought to be in its own section, closer
> to the top.

I'm not sure I follow you here? As I re-read §7 I think it might make
sense to break it into two pieces, one on grants and one on client
auth.  Maybe a 7.1 and a 7.2 or maybe subsections of §4, like a §4.1.1
for client authentication errors and §4.2.1 for authz/grant errors.
But I don't think that was what your comment was about?

Was your comment that this text should live somewhere else?
  "Token endpoints can differentiate between assertion based
   credentials and other client credential types by looking for the
   presence of the client_assertion and client_assertion_type attributes
   which will only be present when using assertions for client
   authentication."

I wouldn't disagree with you there, if that was the case.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[Mike Jones]

Thanks for asking these questions Hannes.  I'll first provide a brief feature 
comparison of Simple Web Discovery and WebFinger and then answer your questions.

FEATURE COMPARISON

RESULT GRANULARITY AND PRIVACY CHARACTERISTICS:  SWD returns the resource 
location(s) for a specific resource for a specific principal.  WebFinger 
returns all resources for the principal.  The example at 
http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-3.2 
"Retrieving a Person's Contact Information" is telling.  The WebFinger usage 
model seems to be "I'll get everything about you and then fish through it to 
decide what to do with it."  The protocol assumption that all WebFinger 
information must be public is also built into the protocol where the CORS 
response header "Access-Control-Allow-Origin: *" is mandated, per 
http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03#section-7.  The 
privacy characteristics of these approaches are very different.  (It's these 
very same privacy characteristics that led sysadmins to nearly ubiquitously 
disabling the fingerd service!)  Particularly for the OAuth use cases, narrow, 
scoped, and potentially permissioned res
 ponses seem preferable.

DOCUMENT VERSUS API MODEL, DEPLOYABILITY, AND SECURITY:  WebFinger is built on 
a "document model", where a single document is returned that contains multiple 
resources for a principal.  SWD is built on an "API model", where the 
location(s) of a particular resource for a principal are returned.  The problem 
with the document model is that different parties or services may be 
authoritative for different resources for a given principal, and yet all need 
the rights to edit the resulting document.  This hurts deployability, because 
document edits then need to be coordinated among parties that may have 
different rights and responsibilities, and may have negative security 
implications as well.  (Just because I can change your avatar doesn't mean that 
I should be able to change your mail server.)

REDIRECT FUNCTIONALITY AND DEPLOYABILTY:  SWD includes the ability to redirect 
some or all SWD requests to another location (possibly depending upon the 
specific resource and principal parameters).  Deployers hosting numerous sites 
for others told the SWD authors that this functionality is critical for 
deployability, as it means that the SWD server for a domain can live in a 
location outside the domain.  WebFinger is lacking this functionality.  Given 
that OAuth is likely to be used in hosted environments, this functionality 
seems pretty important.

NUMBER OF ROUND TRIPS:  WebFinger discoveries for user information normally 
require both a host-meta query to retrieve the template and then a second query 
to retrieve the user's information.  This functionality is achieved in a single 
SWD query.

XML AND JSON VERSUS JSON:  WebFinger specifies both XML and JSON support, 
whereas SWD specifies only JSON.  The SWD position is that it's simpler to 
specify only one way of doing the same thing, with JSON being chosen because 
it's simpler for developers to use than XML - the same decision as made for the 
OAuth specs.

DEFINING SPECIFIC RESOURCES:  Besides specifying a discovery protocol, 
WebFinger also defines specific resources and kinds of resources to be used 
with that protocol:  the "acct" URI scheme, the "acct" Link Relation.  These 
should be considered on their own merits, but logically should be decoupled 
from the discovery protocol into a different document or documents.  It's not 
clear these features would be needed in OAuth contexts.

QUESTIONS

1) Aren't these two mechanisms solving pretty much the same problem?

   They are solving an overlapping set of problems, but with very 
different privacy characteristics, different deployability characteristics, 
different security characteristics, and somewhat different mechanisms.

2) Do we need to have two standards for the same functionality?

   No - Simple Web Discovery is sufficient for the OAuth use cases 
(and likely for others as well).

3) Do you guys have a position or comments regarding either one of them?

   The functionality in Simple Web Discovery is minimal and 
sufficient for the OAuth use cases, whereas some of the functionality and 
assumptions made in WebFinger are harmful, both from a privacy and from a 
deployability perspective.  SWD should proceed to standardization; WebFinger 
should not.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of 
Hannes Tschofenig
Sent: Thursday, April 12, 2012 4:00 AM
To: oauth@ietf.org WG
Subject: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

Hi all, 

those who had attended the last IETF meeting may have noticed the ongoing 
activity in the 'Applications Area Working Group' regarding Web Finger. 
We had our discussion regarding Simple Web Discovery

[OAUTH-WG] typo/missing word in JWT and SAML I-Ds

[Brian Campbell]

I was putting together a little summary writeup on some of these
drafts yesterday and I noticed a missing "a" in the abstract of
http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03 - it says,
"This specification defines the use of a JSON Web Token (JWT) Bearer
Token as means for requesting..." but should probably say "This
specification defines the use of a JSON Web Token (JWT) Bearer  Token
as *a* means for requesting..."

And http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-10 has
nearly the identical omission.

The latter draft is in WGLC and I wasn't sure if I should produce a
new revision to correct this little editorial item now or wait until
after last call?
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

[Mike Jones]

I agree that this looks good.  My only suggestion is that we move up the 
proposed submission dates for JWT and JWT Profile from March 2013 to November 
2012, since the JOSE specs that JWT is largely based upon are scheduled for 
submission in July, per http://datatracker.ietf.org/wg/jose/charter/.

-- Mike

-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Igor 
Faynberg
Sent: Thursday, April 12, 2012 9:58 AM
To: oauth@ietf.org
Subject: Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

Hannes,

I took a look (a bit longer than just "quick"), and what I see completely 
coincides with my understanding of the result of the discussions.

Good job!

Igor

On 4/12/2012 6:55 AM, Hannes Tschofenig wrote:
> Hey guys
>
> based on the discussion before, during, and after the Paris IETF meeting I am 
> going to send the following updated charter / milestones to the IESG.
> Please have a quick look (till the end of the week) to double-check the 
> content (particularly the suggested milestone dates):
>
> --
>
>
> Web Authorization Protocol (oauth)
>
> Description of Working Group
>
> The Web Authorization (OAuth) protocol allows a user to grant a 
> third-party Web site or application access to the user's protected 
> resources, without necessarily revealing their long-term credentials, 
> or even their identity. For example, a photo-sharing site that 
> supports OAuth could allow its users to use a third-party printing Web 
> site to print their private pictures, without allowing the printing 
> site to gain full control of the user's account and without having the 
> user sharing his or her photo-sharing sites' long-term credential with 
> the printing site.
>
> The OAuth protocol suite encompasses
> * a procedure for allowing a client to discover a resource server,
> * a protocol for obtaining authorization tokens from an authorization 
> server with the resource owner's consent,
> * protocols for presenting these authorization tokens to protected 
> resources for access to a resource, and
> * consequently for sharing data in a security and privacy respective way.
>
> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work, 
> was published as an informational document (RFC 5849). With the 
> completion of OAuth 1.0 the working group started their work on OAuth 
> 2.0 to incorporate implementation experience with version 1.0, 
> additional use cases, and various other security, readability, and 
> interoperability improvements. An extensive security analysis was 
> conducted and the result is available as a stand-alone document 
> offering guidance for audiences beyond the community of protocol implementers.
>
> The working group also developed security schemes for presenting 
> authorization tokens to access a protected resource. This led to the 
> publication of the bearer token as well as the message authentication 
> code (MAC) access authentication specification.
>
> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH 
> token with the SAML 2.0 bearer assertion profile.  This offers 
> interworking with existing identity management solutions, in particular SAML 
> based deployments.
>
> OAuth has enjoyed widespread adoption by the Internet application 
> service provider community. To build on this success we aim for 
> nothing more than to make OAuth the authorization framework of choice 
> for any Internet protocol. Consequently, the ongoing standardization 
> effort within the OAuth working group is focused on enhancing 
> interoperability of OAuth deployments. While the core OAuth 
> specification truly is an important building block it relies on other 
> specifications in order to claim completeness. Luckily, these 
> components already exist and have been deployed on the Internet. Through the 
> IETF standards process they will be improved in quality and will undergo a 
> rigorous review process.
>
> Goals and Milestones
>
> [Editor's Note: Here are the completed items.]
>
> Done  Submit 'OAuth 2.0 Threat Model and Security Considerations' as a 
> working group item Done  Submit 'HTTP Authentication: MAC 
> Authentication' as a working group item Done  Submit 'The OAuth 2.0 
> Protocol: Bearer Tokens' to the IESG for consideration as a Proposed 
> Standard Done  Submit 'The OAuth 2.0 Authorization Protocol' to the 
> IESG for consideration as a Proposed Standard
>
> [Editor's Note: Finishing existing work. Double-check the proposed 
> dates - are they realistic?]
>
> May  2012  Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' 
> to the IESG for consideration as a Proposed Standard May  2012  Submit 
> 'OAuth 2.0 Assertion Profile' to the IESG for consideration as a 
> Proposed Standard May  2012  Submit 'An IETF URN Sub-Namespace for 
> OAuth' to the IESG for consideration as a Proposed Standard May  2012  
> Submit 'OAuth 2.0 Threat Model and Security Consideration

Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[John Bradley]

There is no reason that SWD would not be a host service that host-meta could 
list like any other.

That should be supported now by the host-meta spec.  

The question is client complexity.   

A client could look in host-meta and do SWD if it finds that service and no 
mapping template, or the other way around.  

The question is do we want to add the complexity to clients where they have to 
support multiple discovery specs.

I seem to recall people calling me the devil for XRI resolution in openID 2.0.
Not to offend but Web Finger is XRI resolution without the central registry.

John B.


On 2012-04-12, at 8:29 PM, Igor Faynberg wrote:

> John,
> 
> I agree with you on everything you said about the differences.  My question: 
> Are these not about API rather than the protocol?
> 
> (I was just trying to see if I can find a common fixed point to start with.)
> 
> Igor
> 
> On 4/12/2012 2:00 PM, John Bradley wrote:
>> There are important deployment and privacy issues that caused openID Connect 
>> to use SWD.
>> 
>> I was part of the OASIS XRI/XRD work that Web Finger has been based on.
>> 
>> The main differences are around allowing all of the users information to be 
>> publicly discoverable, vs providing for access control.
>> 
>> They are similar, but have real design differences.
>> 
>> Web Finger without XML is not horrible by any means,  but nether is SWD.
>> 
>> SWD is more about users while host-meta is more about server resources.
>> 
>> John B.
>> 
>> 
>> On 2012-04-12, at 7:33 PM, Igor Faynberg wrote:
>> 
>>> To me this looks like more than the same problem being solved--it appears 
>>> to be the same protocol... I wonder if, the representation issues were put 
>>> aside (i.e., left to the API specification), the common part is what can be 
>>> adopted.
>>> 
>>> Igor
>>> 
>>> On 4/12/2012 8:01 AM, Stephen Farrell wrote:
 
 On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
> Hi all,
> 
> those who had attended the last IETF meeting may have noticed the ongoing 
> activity in the 'Applications Area Working Group' regarding Web Finger.
> We had our discussion regarding Simple Web Discovery (SWD) as part of the 
> re-chartering process.
> 
> Here are the two specifications:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02
> 
> Now, the questions that seems to be hanging around are
> 
>   1) Aren't these two mechanisms solving pretty much the same problem?
>   2) Do we need to have two standards for the same functionality?
>   3) Do you guys have a position or comments regarding either one of them?
> 
> Ciao
> Hannes
> 
> PS: Please also let me know if your view is: "I don't really know what 
> all this is about and the documents actually don't provide enough 
> requirements to make a reasonable judgement about the solution space."
> 
 So just as a data-point. We (the IETF, but including
 me personally;-) mucked up badly on this some years
 ago in the PKI space - we standardised both CMP (rfc
 2510) and CMC (rfc 2797) as two ways to do the same
 thing, after a protracted battle between factions
 supporting one or the other. We even made sure they
 had as much common syntax as possible. (CRMF, rfc
 2511)
 
 Result: neither fully adopted, lots of people still
 do proprietary stuff, neither can be killed off
 (despite attempts), both need to be maintained (CMP
 is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO
 partly as a result of us screwing up for what seemed
 like good reasons at the time, PKI administration
 stuff has never gotten beyond horrible-to-do.
 
 All-in-all, a really bad outcome which is still
 a PITA a dozen years later.
 
 As OAuth AD I will need *serious* convincing that
 there is a need to provide two ways to do the same
 thing. I doubt it'll be possible to convince me,
 in fact, so if you wanna try, you'll need to start
 by saying that they are not in fact two ways to do
 the same thing:-)
 
 S.
 
 PS: This discussion needs to also involve the Apps
 area, so I've cc'd that list.
 
> 
> 
> ___
> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

[OAUTH-WG] Using OAuth to get a JWT/SAML token

[Lewis Adam-CAL022]

Hi all,

I've been talking to some of you off line about this already, but I need some 
help in terms of implementation.  I would like to use OAuth as a means to get 
either a JWT or SAML token to a client running on a handheld device.  This is 
something that I'm looking to prototype (as part of a larger project) beginning 
this week.  So, it is important to me to understand the divide between what is 
theoretically possible and what is actually possible.

Anybody aware of any implementations out there, either vendor or open source, 
that I can use for this?

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

Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[John Bradley]

SWD takes more of a API approach where a query is made about a specific 
resource type about a specific subject (email format or URI ).

The current draft of the spec doesn't go into detail on how a requester is 
identified and given authorization to discover the resource.   One could 
imagine that being done with OAuth. 

You could do a similar thing with web finger, however given that the typical 
deployment is more of a document model, that is harder for some large sites to 
deploy. 

Is everything in SWD fully sorted out, well no otherwise it would not be bing 
brought to the IETF for standardization.

As we discussed in Paris many of the goals are similar but there are 
implementation differences. 

I could also say that the Web Finger approach is more user-centric for sites 
where users have direct control over editing there own pages.

In most cases, that is not the reality however. 

John B.
On 2012-04-12, at 8:18 PM, Eran Hammer wrote:

> Where is this access control and user centric architecture described? I could 
> not find it. 
> 
> EH
> 
> On Apr 12, 2012, at 14:01, "John Bradley"  wrote:
> 
>> There are important deployment and privacy issues that caused openID Connect 
>> to use SWD.
>> 
>> I was part of the OASIS XRI/XRD work that Web Finger has been based on.
>> 
>> The main differences are around allowing all of the users information to be 
>> publicly discoverable, vs providing for access control. 
>> 
>> They are similar, but have real design differences.
>> 
>> Web Finger without XML is not horrible by any means,  but nether is SWD.
>> 
>> SWD is more about users while host-meta is more about server resources.
>> 
>> John B.
>> 
>> 
>> On 2012-04-12, at 7:33 PM, Igor Faynberg wrote:
>> 
>>> To me this looks like more than the same problem being solved--it appears 
>>> to be the same protocol... I wonder if, the representation issues were put 
>>> aside (i.e., left to the API specification), the common part is what can be 
>>> adopted.
>>> 
>>> Igor
>>> 
>>> On 4/12/2012 8:01 AM, Stephen Farrell wrote:
 
 
 On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
> Hi all,
> 
> those who had attended the last IETF meeting may have noticed the ongoing 
> activity in the 'Applications Area Working Group' regarding Web Finger.
> We had our discussion regarding Simple Web Discovery (SWD) as part of the 
> re-chartering process.
> 
> Here are the two specifications:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02
> 
> Now, the questions that seems to be hanging around are
> 
> 1) Aren't these two mechanisms solving pretty much the same problem?
> 2) Do we need to have two standards for the same functionality?
> 3) Do you guys have a position or comments regarding either one of them?
> 
> Ciao
> Hannes
> 
> PS: Please also let me know if your view is: "I don't really know what 
> all this is about and the documents actually don't provide enough 
> requirements to make a reasonable judgement about the solution space."
> 
 
 So just as a data-point. We (the IETF, but including
 me personally;-) mucked up badly on this some years
 ago in the PKI space - we standardised both CMP (rfc
 2510) and CMC (rfc 2797) as two ways to do the same
 thing, after a protracted battle between factions
 supporting one or the other. We even made sure they
 had as much common syntax as possible. (CRMF, rfc
 2511)
 
 Result: neither fully adopted, lots of people still
 do proprietary stuff, neither can be killed off
 (despite attempts), both need to be maintained (CMP
 is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO
 partly as a result of us screwing up for what seemed
 like good reasons at the time, PKI administration
 stuff has never gotten beyond horrible-to-do.
 
 All-in-all, a really bad outcome which is still
 a PITA a dozen years later.
 
 As OAuth AD I will need *serious* convincing that
 there is a need to provide two ways to do the same
 thing. I doubt it'll be possible to convince me,
 in fact, so if you wanna try, you'll need to start
 by saying that they are not in fact two ways to do
 the same thing:-)
 
 S.
 
 PS: This discussion needs to also involve the Apps
 area, so I've cc'd that list.
 
> 
> 
> 
> ___
> 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] Web Finger vs. Simple Web Discovery (SWD)

[Igor Faynberg]

John,

 I agree with you on everything you said about the differences.  My 
question: Are these not about API rather than the protocol?


(I was just trying to see if I can find a common fixed point to start with.)

Igor

On 4/12/2012 2:00 PM, John Bradley wrote:

There are important deployment and privacy issues that caused openID Connect to 
use SWD.

I was part of the OASIS XRI/XRD work that Web Finger has been based on.

The main differences are around allowing all of the users information to be 
publicly discoverable, vs providing for access control.

They are similar, but have real design differences.

Web Finger without XML is not horrible by any means,  but nether is SWD.

SWD is more about users while host-meta is more about server resources.

John B.


On 2012-04-12, at 7:33 PM, Igor Faynberg wrote:


To me this looks like more than the same problem being solved--it appears to be 
the same protocol... I wonder if, the representation issues were put aside 
(i.e., left to the API specification), the common part is what can be adopted.

Igor

On 4/12/2012 8:01 AM, Stephen Farrell wrote:


On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:

Hi all,

those who had attended the last IETF meeting may have noticed the ongoing 
activity in the 'Applications Area Working Group' regarding Web Finger.
We had our discussion regarding Simple Web Discovery (SWD) as part of the 
re-chartering process.

Here are the two specifications:
http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
http://tools.ietf.org/html/draft-jones-simple-web-discovery-02

Now, the questions that seems to be hanging around are

   1) Aren't these two mechanisms solving pretty much the same problem?
   2) Do we need to have two standards for the same functionality?
   3) Do you guys have a position or comments regarding either one of them?

Ciao
Hannes

PS: Please also let me know if your view is: "I don't really know what all this is 
about and the documents actually don't provide enough requirements to make a reasonable 
judgement about the solution space."


So just as a data-point. We (the IETF, but including
me personally;-) mucked up badly on this some years
ago in the PKI space - we standardised both CMP (rfc
2510) and CMC (rfc 2797) as two ways to do the same
thing, after a protracted battle between factions
supporting one or the other. We even made sure they
had as much common syntax as possible. (CRMF, rfc
2511)

Result: neither fully adopted, lots of people still
do proprietary stuff, neither can be killed off
(despite attempts), both need to be maintained (CMP
is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO
partly as a result of us screwing up for what seemed
like good reasons at the time, PKI administration
stuff has never gotten beyond horrible-to-do.

All-in-all, a really bad outcome which is still
a PITA a dozen years later.

As OAuth AD I will need *serious* convincing that
there is a need to provide two ways to do the same
thing. I doubt it'll be possible to convince me,
in fact, so if you wanna try, you'll need to start
by saying that they are not in fact two ways to do
the same thing:-)

S.

PS: This discussion needs to also involve the Apps
area, so I've cc'd that list.




___
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] Web Finger vs. Simple Web Discovery (SWD)

[Eran Hammer]

Where is this access control and user centric architecture described? I could 
not find it. 

EH

On Apr 12, 2012, at 14:01, "John Bradley"  wrote:

> There are important deployment and privacy issues that caused openID Connect 
> to use SWD.
> 
> I was part of the OASIS XRI/XRD work that Web Finger has been based on.
> 
> The main differences are around allowing all of the users information to be 
> publicly discoverable, vs providing for access control. 
> 
> They are similar, but have real design differences.
> 
> Web Finger without XML is not horrible by any means,  but nether is SWD.
> 
> SWD is more about users while host-meta is more about server resources.
> 
> John B.
> 
> 
> On 2012-04-12, at 7:33 PM, Igor Faynberg wrote:
> 
>> To me this looks like more than the same problem being solved--it appears to 
>> be the same protocol... I wonder if, the representation issues were put 
>> aside (i.e., left to the API specification), the common part is what can be 
>> adopted.
>> 
>> Igor
>> 
>> On 4/12/2012 8:01 AM, Stephen Farrell wrote:
>>> 
>>> 
>>> On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
 Hi all,
 
 those who had attended the last IETF meeting may have noticed the ongoing 
 activity in the 'Applications Area Working Group' regarding Web Finger.
 We had our discussion regarding Simple Web Discovery (SWD) as part of the 
 re-chartering process.
 
 Here are the two specifications:
 http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
 http://tools.ietf.org/html/draft-jones-simple-web-discovery-02
 
 Now, the questions that seems to be hanging around are
 
  1) Aren't these two mechanisms solving pretty much the same problem?
  2) Do we need to have two standards for the same functionality?
  3) Do you guys have a position or comments regarding either one of them?
 
 Ciao
 Hannes
 
 PS: Please also let me know if your view is: "I don't really know what all 
 this is about and the documents actually don't provide enough requirements 
 to make a reasonable judgement about the solution space."
 
>>> 
>>> So just as a data-point. We (the IETF, but including
>>> me personally;-) mucked up badly on this some years
>>> ago in the PKI space - we standardised both CMP (rfc
>>> 2510) and CMC (rfc 2797) as two ways to do the same
>>> thing, after a protracted battle between factions
>>> supporting one or the other. We even made sure they
>>> had as much common syntax as possible. (CRMF, rfc
>>> 2511)
>>> 
>>> Result: neither fully adopted, lots of people still
>>> do proprietary stuff, neither can be killed off
>>> (despite attempts), both need to be maintained (CMP
>>> is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO
>>> partly as a result of us screwing up for what seemed
>>> like good reasons at the time, PKI administration
>>> stuff has never gotten beyond horrible-to-do.
>>> 
>>> All-in-all, a really bad outcome which is still
>>> a PITA a dozen years later.
>>> 
>>> As OAuth AD I will need *serious* convincing that
>>> there is a need to provide two ways to do the same
>>> thing. I doubt it'll be possible to convince me,
>>> in fact, so if you wanna try, you'll need to start
>>> by saying that they are not in fact two ways to do
>>> the same thing:-)
>>> 
>>> S.
>>> 
>>> PS: This discussion needs to also involve the Apps
>>> area, so I've cc'd that list.
>>> 
 
 
 
 ___
 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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[John Bradley]

There are important deployment and privacy issues that caused openID Connect to 
use SWD.

I was part of the OASIS XRI/XRD work that Web Finger has been based on.

The main differences are around allowing all of the users information to be 
publicly discoverable, vs providing for access control. 

They are similar, but have real design differences.

Web Finger without XML is not horrible by any means,  but nether is SWD.

SWD is more about users while host-meta is more about server resources.

John B.


On 2012-04-12, at 7:33 PM, Igor Faynberg wrote:

> To me this looks like more than the same problem being solved--it appears to 
> be the same protocol... I wonder if, the representation issues were put aside 
> (i.e., left to the API specification), the common part is what can be adopted.
> 
> Igor
> 
> On 4/12/2012 8:01 AM, Stephen Farrell wrote:
>> 
>> 
>> On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
>> > Hi all,
>> >
>> > those who had attended the last IETF meeting may have noticed the ongoing 
>> > activity in the 'Applications Area Working Group' regarding Web Finger.
>> > We had our discussion regarding Simple Web Discovery (SWD) as part of the 
>> > re-chartering process.
>> >
>> > Here are the two specifications:
>> > http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
>> > http://tools.ietf.org/html/draft-jones-simple-web-discovery-02
>> >
>> > Now, the questions that seems to be hanging around are
>> >
>> >   1) Aren't these two mechanisms solving pretty much the same problem?
>> >   2) Do we need to have two standards for the same functionality?
>> >   3) Do you guys have a position or comments regarding either one of them?
>> >
>> > Ciao
>> > Hannes
>> >
>> > PS: Please also let me know if your view is: "I don't really know what all 
>> > this is about and the documents actually don't provide enough requirements 
>> > to make a reasonable judgement about the solution space."
>> >
>> 
>> So just as a data-point. We (the IETF, but including
>> me personally;-) mucked up badly on this some years
>> ago in the PKI space - we standardised both CMP (rfc
>> 2510) and CMC (rfc 2797) as two ways to do the same
>> thing, after a protracted battle between factions
>> supporting one or the other. We even made sure they
>> had as much common syntax as possible. (CRMF, rfc
>> 2511)
>> 
>> Result: neither fully adopted, lots of people still
>> do proprietary stuff, neither can be killed off
>> (despite attempts), both need to be maintained (CMP
>> is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO
>> partly as a result of us screwing up for what seemed
>> like good reasons at the time, PKI administration
>> stuff has never gotten beyond horrible-to-do.
>> 
>> All-in-all, a really bad outcome which is still
>> a PITA a dozen years later.
>> 
>> As OAuth AD I will need *serious* convincing that
>> there is a need to provide two ways to do the same
>> thing. I doubt it'll be possible to convince me,
>> in fact, so if you wanna try, you'll need to start
>> by saying that they are not in fact two ways to do
>> the same thing:-)
>> 
>> S.
>> 
>> PS: This discussion needs to also involve the Apps
>> area, so I've cc'd that list.
>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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



smime.p7s
Description: S/MIME cryptographic signature
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[Igor Faynberg]

To me this looks like more than the same problem being solved--it 
appears to be the same protocol... I wonder if, the representation 
issues were put aside (i.e., left to the API specification), the common 
part is what can be adopted.


Igor

On 4/12/2012 8:01 AM, Stephen Farrell wrote:



On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
> Hi all,
>
> those who had attended the last IETF meeting may have noticed the 
ongoing activity in the 'Applications Area Working Group' regarding 
Web Finger.
> We had our discussion regarding Simple Web Discovery (SWD) as part 
of the re-chartering process.

>
> Here are the two specifications:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02
>
> Now, the questions that seems to be hanging around are
>
>   1) Aren't these two mechanisms solving pretty much the same problem?
>   2) Do we need to have two standards for the same functionality?
>   3) Do you guys have a position or comments regarding either one of 
them?

>
> Ciao
> Hannes
>
> PS: Please also let me know if your view is: "I don't really know 
what all this is about and the documents actually don't provide enough 
requirements to make a reasonable judgement about the solution space."

>

So just as a data-point. We (the IETF, but including
me personally;-) mucked up badly on this some years
ago in the PKI space - we standardised both CMP (rfc
2510) and CMC (rfc 2797) as two ways to do the same
thing, after a protracted battle between factions
supporting one or the other. We even made sure they
had as much common syntax as possible. (CRMF, rfc
2511)

Result: neither fully adopted, lots of people still
do proprietary stuff, neither can be killed off
(despite attempts), both need to be maintained (CMP
is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO
partly as a result of us screwing up for what seemed
like good reasons at the time, PKI administration
stuff has never gotten beyond horrible-to-do.

All-in-all, a really bad outcome which is still
a PITA a dozen years later.

As OAuth AD I will need *serious* convincing that
there is a need to provide two ways to do the same
thing. I doubt it'll be possible to convince me,
in fact, so if you wanna try, you'll need to start
by saying that they are not in fact two ways to do
the same thing:-)

S.

PS: This discussion needs to also involve the Apps
area, so I've cc'd that list.





___
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] Updated Charter to the IESG (this weekend)

[Igor Faynberg]

Hannes,

I took a look (a bit longer than just "quick"), and what I see 
completely coincides with my understanding of the result of the discussions.


Good job!

Igor

On 4/12/2012 6:55 AM, Hannes Tschofenig wrote:

Hey guys

based on the discussion before, during, and after the Paris IETF meeting I am 
going to send the following updated charter / milestones to the IESG.
Please have a quick look (till the end of the week) to double-check the content 
(particularly the suggested milestone dates):

--


Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user
sharing his or her photo-sharing sites' long-term credential with the
printing site.

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these authorization tokens to protected
resources for access to a resource, and
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result
is available as a stand-alone document offering guidance for audiences
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access
authentication specification.

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token 
with
the SAML 2.0 bearer assertion profile.  This offers interworking with existing
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service 
provider
community. To build on this success we aim for nothing more than to make OAuth 
the
authorization framework of choice for any Internet protocol. Consequently, the
ongoing standardization effort within the OAuth working group is focused on
enhancing interoperability of OAuth deployments. While the core OAuth 
specification
truly is an important building block it relies on other specifications in order 
to
claim completeness. Luckily, these components already exist and have been 
deployed
on the Internet. Through the IETF standards process they will be improved in
quality and will undergo a rigorous review process.

Goals and Milestones

[Editor's Note: Here are the completed items.]

Done  Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working 
group item
Done  Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done  Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for 
consideration as a Proposed Standard
Done  Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for 
consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - are 
they realistic?]

May  2012  Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the 
IESG for consideration as a Proposed Standard
May  2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration 
as a Proposed Standard
May  2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for 
consideration as a Proposed Standard
May  2012  Submit 'OAuth 2.0 Threat Model and Security Considerations' to the 
IESG for consideration as an Informational RFC
Dec. 2012  Submit 'HTTP Authentication: MAC Authentication' to the IESG for 
consideration as a Proposed Standard

[Editor's Note: New work for the group]

Nov. 2012  Submit 'Token Revocation' to the IESG for consideration as a 
Proposed Standard

[Starting point for the work will be 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Dec. 2012  Submit 'OAuth Use Cases' to the IESG for consideration as an 
Informational RFC

[Starting point for the work will be 
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]

Jan. 2013  Submit 'Simple Web Discovery' to the IESG for consideration as a 
Proposed Standard

[Starting point for the work will be 
http://tools.ietf.org/htm

Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

[Paul Madsen]

Hi Hannes, do you mean 'discover relevant OAuth endpoints *for* a 
resource server'? ie instead of discovering the RS itself?


On 4/12/12 6:55 AM, Hannes Tschofenig wrote:

Hey guys

based on the discussion before, during, and after the Paris IETF meeting I am 
going to send the following updated charter / milestones to the IESG.
Please have a quick look (till the end of the week) to double-check the content 
(particularly the suggested milestone dates):

--


Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user
sharing his or her photo-sharing sites' long-term credential with the
printing site.

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server,
* a protocol for obtaining authorization tokens from an authorization
server with the resource owner's consent,
* protocols for presenting these authorization tokens to protected
resources for access to a resource, and
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result
is available as a stand-alone document offering guidance for audiences
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access
authentication specification.

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token 
with
the SAML 2.0 bearer assertion profile.  This offers interworking with existing
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service 
provider
community. To build on this success we aim for nothing more than to make OAuth 
the
authorization framework of choice for any Internet protocol. Consequently, the
ongoing standardization effort within the OAuth working group is focused on
enhancing interoperability of OAuth deployments. While the core OAuth 
specification
truly is an important building block it relies on other specifications in order 
to
claim completeness. Luckily, these components already exist and have been 
deployed
on the Internet. Through the IETF standards process they will be improved in
quality and will undergo a rigorous review process.

Goals and Milestones

[Editor's Note: Here are the completed items.]

Done  Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working 
group item
Done  Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done  Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for 
consideration as a Proposed Standard
Done  Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for 
consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - are 
they realistic?]

May  2012  Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the 
IESG for consideration as a Proposed Standard
May  2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration 
as a Proposed Standard
May  2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for 
consideration as a Proposed Standard
May  2012  Submit 'OAuth 2.0 Threat Model and Security Considerations' to the 
IESG for consideration as an Informational RFC
Dec. 2012  Submit 'HTTP Authentication: MAC Authentication' to the IESG for 
consideration as a Proposed Standard

[Editor's Note: New work for the group]

Nov. 2012  Submit 'Token Revocation' to the IESG for consideration as a 
Proposed Standard

[Starting point for the work will be 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Dec. 2012  Submit 'OAuth Use Cases' to the IESG for consideration as an 
Informational RFC

[Starting point for the work will be 
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases]

Jan. 2013  Submit 'Simple Web Discovery' to the IESG for consideration as a 
Proposed Standard

[Starting point for the work will be 
http://tools.ietf.org/html/draft-jones-simple-web-discovery]

Mar. 20

[OAUTH-WG] where do error codes go?, was: Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

[Julian Reschke]

On 2012-04-10 16:03, Alexey Melnikov wrote:

...
2). Section "3.1. Error Codes"

I've suggested to use an IANA registry for this field. Apparently there
is already a registry created by
.
However this document doesn't register values defined in section 3.1
with IANA and doesn't point to draft-ietf-oauth-v2-23 for the registry.
I find this to be very confusing.
...


Speaking of which, how is an error code returned if the HTTP status is 
*not* 401?


3.1. Error Codes


   When a request fails, the resource server responds using the
   appropriate HTTP status code (typically, 400, 401, 403, or 405), and
   includes one of the following error codes in the response:

   invalid_request
 The request is missing a required parameter, includes an
 unsupported parameter or parameter value, repeats the same
 parameter, uses more than one method for including an access
 token, or is otherwise malformed.  The resource server SHOULD
 respond with the HTTP 400 (Bad Request) status code.

   ...

Is the assumption that the response body is always application/json in 
that case? It might be good to clarify that.


Best regards, Julian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Updated Charter to the IESG (this weekend)

[Eran Hammer]

With the exception of SWD which is still being discussed, this looks good. 

EH

On Apr 12, 2012, at 6:55, "Hannes Tschofenig"  wrote:

> Hey guys
> 
> based on the discussion before, during, and after the Paris IETF meeting I am 
> going to send the following updated charter / milestones to the IESG.
> Please have a quick look (till the end of the week) to double-check the 
> content (particularly the suggested milestone dates):
> 
> --
> 
> 
> Web Authorization Protocol (oauth)
> 
> Description of Working Group
> 
> The Web Authorization (OAuth) protocol allows a user to grant
> a third-party Web site or application access to the user's protected
> resources, without necessarily revealing their long-term credentials,
> or even their identity. For example, a photo-sharing site that supports
> OAuth could allow its users to use a third-party printing Web site to
> print their private pictures, without allowing the printing site to
> gain full control of the user's account and without having the user 
> sharing his or her photo-sharing sites' long-term credential with the 
> printing site. 
> 
> The OAuth protocol suite encompasses
> * a procedure for allowing a client to discover a resource server, 
> * a protocol for obtaining authorization tokens from an authorization 
> server with the resource owner's consent, 
> * protocols for presenting these authorization tokens to protected 
> resources for access to a resource, and 
> * consequently for sharing data in a security and privacy respective way.
> 
> In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
> was published as an informational document (RFC 5849). With the 
> completion of OAuth 1.0 the working group started their work on OAuth 2.0
> to incorporate implementation experience with version 1.0, additional
> use cases, and various other security, readability, and interoperability
> improvements. An extensive security analysis was conducted and the result 
> is available as a stand-alone document offering guidance for audiences 
> beyond the community of protocol implementers.
> 
> The working group also developed security schemes for presenting authorization
> tokens to access a protected resource. This led to the publication of
> the bearer token as well as the message authentication code (MAC) access 
> authentication specification. 
> 
> OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token 
> with 
> the SAML 2.0 bearer assertion profile.  This offers interworking with 
> existing 
> identity management solutions, in particular SAML based deployments.
> 
> OAuth has enjoyed widespread adoption by the Internet application service 
> provider 
> community. To build on this success we aim for nothing more than to make 
> OAuth the 
> authorization framework of choice for any Internet protocol. Consequently, 
> the 
> ongoing standardization effort within the OAuth working group is focused on 
> enhancing interoperability of OAuth deployments. While the core OAuth 
> specification 
> truly is an important building block it relies on other specifications in 
> order to 
> claim completeness. Luckily, these components already exist and have been 
> deployed 
> on the Internet. Through the IETF standards process they will be improved in 
> quality and will undergo a rigorous review process. 
> 
> Goals and Milestones
> 
> [Editor's Note: Here are the completed items.] 
> 
> Done  Submit 'OAuth 2.0 Threat Model and Security Considerations' as a 
> working group item
> Done  Submit 'HTTP Authentication: MAC Authentication' as a working group item
> Done  Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for 
> consideration as a Proposed Standard
> Done  Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for 
> consideration as a Proposed Standard
> 
> [Editor's Note: Finishing existing work. Double-check the proposed dates - 
> are they realistic?] 
> 
> May  2012  Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the 
> IESG for consideration as a Proposed Standard
> May  2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration 
> as a Proposed Standard 
> May  2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for 
> consideration as a Proposed Standard 
> May  2012  Submit 'OAuth 2.0 Threat Model and Security Considerations' to the 
> IESG for consideration as an Informational RFC
> Dec. 2012  Submit 'HTTP Authentication: MAC Authentication' to the IESG for 
> consideration as a Proposed Standard
> 
> [Editor's Note: New work for the group]
> 
> Nov. 2012  Submit 'Token Revocation' to the IESG for consideration as a 
> Proposed Standard
> 
> [Starting point for the work will be 
> http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]
> 
> Dec. 2012  Submit 'OAuth Use Cases' to the IESG for consideration as an 
> Informational RFC
> 
> [Starting point for the work will be 
> http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases

Re: [OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[Stephen Farrell]

On 04/12/2012 12:00 PM, Hannes Tschofenig wrote:
> Hi all,
>
> those who had attended the last IETF meeting may have noticed the 
ongoing activity in the 'Applications Area Working Group' regarding Web 
Finger.
> We had our discussion regarding Simple Web Discovery (SWD) as part of 
the re-chartering process.

>
> Here are the two specifications:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02
>
> Now, the questions that seems to be hanging around are
>
>   1) Aren't these two mechanisms solving pretty much the same problem?
>   2) Do we need to have two standards for the same functionality?
>   3) Do you guys have a position or comments regarding either one of 
them?

>
> Ciao
> Hannes
>
> PS: Please also let me know if your view is: "I don't really know 
what all this is about and the documents actually don't provide enough 
requirements to make a reasonable judgement about the solution space."

>

So just as a data-point. We (the IETF, but including
me personally;-) mucked up badly on this some years
ago in the PKI space - we standardised both CMP (rfc
2510) and CMC (rfc 2797) as two ways to do the same
thing, after a protracted battle between factions
supporting one or the other. We even made sure they
had as much common syntax as possible. (CRMF, rfc
2511)

Result: neither fully adopted, lots of people still
do proprietary stuff, neither can be killed off
(despite attempts), both need to be maintained (CMP
is now RFC 4210, CMC, 5272, CRMF, 4211), and IMO
partly as a result of us screwing up for what seemed
like good reasons at the time, PKI administration
stuff has never gotten beyond horrible-to-do.

All-in-all, a really bad outcome which is still
a PITA a dozen years later.

As OAuth AD I will need *serious* convincing that
there is a need to provide two ways to do the same
thing. I doubt it'll be possible to convince me,
in fact, so if you wanna try, you'll need to start
by saying that they are not in fact two ways to do
the same thing:-)

S.

PS: This discussion needs to also involve the Apps
area, so I've cc'd that list.





___
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] Web Finger vs. Simple Web Discovery (SWD)

[Michiel de Jong]

Kudos for bringing this up!

imho, "speccers gonna spec" and it's impossible to stop overlapping
specs from showing up all the time. we'll have to live with the
existence of multiple standards.

Clients will just have to stand above whatever political reasons lie
behind them, and support both, just like DVD players often play like 8
different types of disc formats. We'll just have to query both, and
merge the information we find.

There are three important points regarding the differences between them, imho:
- webfinger mentions CORS, meaning that unlike swd it can be queried
by unhosted html5 apps, and not just server-to-server.
- swd mentions 401 responses, meaning that unlike webfinger, it can be
used to announce information to a limited audience, and not just
public data.
- webfinger starts at /.well-known/host-meta but swd starts at
/.well-known/simple-web-discovery, meaning a relying party will have
to choose which one to check first, and then check the other one in
case additional information lurks there. It would be nice if at least
that part could be reconciled. E.g. if swd requires providers to
(also) be discoverable through host-meta. That way there's one entry
point for both formats. Wouldn't that be nice?

My 2ct,
Michiel.


On Thu, Apr 12, 2012 at 1:00 PM, Hannes Tschofenig
 wrote:
> Hi all,
>
> those who had attended the last IETF meeting may have noticed the ongoing 
> activity in the 'Applications Area Working Group' regarding Web Finger.
> We had our discussion regarding Simple Web Discovery (SWD) as part of the 
> re-chartering process.
>
> Here are the two specifications:
> http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
> http://tools.ietf.org/html/draft-jones-simple-web-discovery-02
>
> Now, the questions that seems to be hanging around are
>
>  1) Aren't these two mechanisms solving pretty much the same problem?
>  2) Do we need to have two standards for the same functionality?
>  3) Do you guys have a position or comments regarding either one of them?
>
> Ciao
> Hannes
>
> PS: Please also let me know if your view is: "I don't really know what all 
> this is about and the documents actually don't provide enough requirements to 
> make a reasonable judgement about the solution space."
>
>
>
>
> ___
> 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] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

[Alexey Melnikov]

On 11/04/2012 01:25, Mike Jones wrote:

Hi Alexey,

Hi Mike,
I've dropped issue 2, Sean took charge of discussing it with IESG.

About your issue 1:  The OAuth Core spec, where "scope" is primarily defined, includes 
the sentence "The [scope] strings are defined by the authorization server" (see 
http://tools.ietf.org/html/draft-ietf-oauth-v2-25#section-3.3).  I could add that clarification to 
the Bearer spec as well to make it clear that the scope values are context-dependent, if that would 
address your concern.
Yes, but only partially. I would also like to see a clear statement that 
there is no centralized registry for scope values, plus some examples 
(more than 1) of how values of this attribute can look like.


With out this information I don't think the spec is implementable.



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

[OAUTH-WG] Web Finger vs. Simple Web Discovery (SWD)

[Hannes Tschofenig]

Hi all, 

those who had attended the last IETF meeting may have noticed the ongoing 
activity in the 'Applications Area Working Group' regarding Web Finger. 
We had our discussion regarding Simple Web Discovery (SWD) as part of the 
re-chartering process. 

Here are the two specifications:
http://tools.ietf.org/html/draft-jones-appsawg-webfinger-03
http://tools.ietf.org/html/draft-jones-simple-web-discovery-02

Now, the questions that seems to be hanging around are

 1) Aren't these two mechanisms solving pretty much the same problem?
 2) Do we need to have two standards for the same functionality?
 3) Do you guys have a position or comments regarding either one of them? 

Ciao
Hannes

PS: Please also let me know if your view is: "I don't really know what all this 
is about and the documents actually don't provide enough requirements to make a 
reasonable judgement about the solution space."




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

[OAUTH-WG] Updated Charter to the IESG (this weekend)

[Hannes Tschofenig]

Hey guys

based on the discussion before, during, and after the Paris IETF meeting I am 
going to send the following updated charter / milestones to the IESG.
Please have a quick look (till the end of the week) to double-check the content 
(particularly the suggested milestone dates):

--


Web Authorization Protocol (oauth)

Description of Working Group

The Web Authorization (OAuth) protocol allows a user to grant
a third-party Web site or application access to the user's protected
resources, without necessarily revealing their long-term credentials,
or even their identity. For example, a photo-sharing site that supports
OAuth could allow its users to use a third-party printing Web site to
print their private pictures, without allowing the printing site to
gain full control of the user's account and without having the user 
sharing his or her photo-sharing sites' long-term credential with the 
printing site. 

The OAuth protocol suite encompasses
* a procedure for allowing a client to discover a resource server, 
* a protocol for obtaining authorization tokens from an authorization 
server with the resource owner's consent, 
* protocols for presenting these authorization tokens to protected 
resources for access to a resource, and 
* consequently for sharing data in a security and privacy respective way.

In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
was published as an informational document (RFC 5849). With the 
completion of OAuth 1.0 the working group started their work on OAuth 2.0
to incorporate implementation experience with version 1.0, additional
use cases, and various other security, readability, and interoperability
improvements. An extensive security analysis was conducted and the result 
is available as a stand-alone document offering guidance for audiences 
beyond the community of protocol implementers.

The working group also developed security schemes for presenting authorization
tokens to access a protected resource. This led to the publication of
the bearer token as well as the message authentication code (MAC) access 
authentication specification. 

OAuth 2.0 added the ability to trade a SAML assertion against an OAUTH token 
with 
the SAML 2.0 bearer assertion profile.  This offers interworking with existing 
identity management solutions, in particular SAML based deployments.

OAuth has enjoyed widespread adoption by the Internet application service 
provider 
community. To build on this success we aim for nothing more than to make OAuth 
the 
authorization framework of choice for any Internet protocol. Consequently, the 
ongoing standardization effort within the OAuth working group is focused on 
enhancing interoperability of OAuth deployments. While the core OAuth 
specification 
truly is an important building block it relies on other specifications in order 
to 
claim completeness. Luckily, these components already exist and have been 
deployed 
on the Internet. Through the IETF standards process they will be improved in 
quality and will undergo a rigorous review process. 

Goals and Milestones

[Editor's Note: Here are the completed items.] 

Done  Submit 'OAuth 2.0 Threat Model and Security Considerations' as a working 
group item
Done  Submit 'HTTP Authentication: MAC Authentication' as a working group item
Done  Submit 'The OAuth 2.0 Protocol: Bearer Tokens' to the IESG for 
consideration as a Proposed Standard
Done  Submit 'The OAuth 2.0 Authorization Protocol' to the IESG for 
consideration as a Proposed Standard

[Editor's Note: Finishing existing work. Double-check the proposed dates - are 
they realistic?] 

May  2012  Submit 'SAML 2.0 Bearer Assertion Profiles for OAuth 2.0' to the 
IESG for consideration as a Proposed Standard
May  2012  Submit 'OAuth 2.0 Assertion Profile' to the IESG for consideration 
as a Proposed Standard 
May  2012  Submit 'An IETF URN Sub-Namespace for OAuth' to the IESG for 
consideration as a Proposed Standard 
May  2012  Submit 'OAuth 2.0 Threat Model and Security Considerations' to the 
IESG for consideration as an Informational RFC
Dec. 2012  Submit 'HTTP Authentication: MAC Authentication' to the IESG for 
consideration as a Proposed Standard

[Editor's Note: New work for the group]

Nov. 2012  Submit 'Token Revocation' to the IESG for consideration as a 
Proposed Standard

[Starting point for the work will be 
http://datatracker.ietf.org/doc/draft-lodderstedt-oauth-revocation/]

Dec. 2012  Submit 'OAuth Use Cases' to the IESG for consideration as an 
Informational RFC

[Starting point for the work will be 
http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases] 

Jan. 2013  Submit 'Simple Web Discovery' to the IESG for consideration as a 
Proposed Standard

[Starting point for the work will be 
http://tools.ietf.org/html/draft-jones-simple-web-discovery] 

Mar. 2013  Submit 'JSON Web Token (JWT)' to the IESG for consideration as a 
Proposed Standard

[Starting point for the work will be 
http://tools.ietf

Re: [OAUTH-WG] Gen-ART Telechat review of draft-ietf-oauth-v2-bearer-18.txt

[Julian Reschke]

Citing from Sean's dicuss 
():



1) I'm hoping the answer to this one is "there's no problem" but I gotta ask and
maybe the APPs ADs can confirm:  Is there any issue with this specification
using ABNF from [I-D.ietf-httpbis-p1-messaging] while OAUTH 2.0 uses [RFC5234]?


The ABNF from HTTPbis is a superset of RFC 5234 in that it defines a 
list rule for readability. I don't think that this rule is used anymore 
in the bearer spec, so it can just say it's using RFC 5234.


Best regards, Julian
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth