Subject: [OAUTH-WG] proposed agenda for second interim meeting

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 02 Feb 2010 22:15:24 -0700

<hat type='chair'/>

At the first interim meeting, we didn't get through our agenda:

http://www.ietf.org/mail-archive/web/oauth/current/msg01013.html

Therefore I propose that this time we focus on some unfinished business,
starting with the topic of authentication. I have reviewed all of the
related threads on the list and have come up with the following *rough*
agenda. Your feedback is welcome to improve this (a.k.a. "agenda
bashing") either on the list or during the meeting.

For logistics information, see here:

http://www.ietf.org/mail-archive/web/oauth/current/msg01085.html

******

AGENDA

Base proposal: draft-ietf-oauth-authentication-01

Eran had hoped to push out a new version in time for our meeting, but
hasn't been able to get to it yet. However, I think we can continue to
move forward with discussion. Feedback is welcome on the general
approach, as well as specific open issues.

Open issues....

Issue #1: Request Signing vs. API Signing vs. Message Signing
http://www.ietf.org/mail-archive/web/oauth/current/msg00961.html

1a. Seeming consensus for message signing.

1b. No consensus yet on message format.
    - JSON and textual key-value seem to be the leading candidates.

1c. Seeming consensus for multiple/extensible signature algorithms.
    - HMAC-SHA1
    - HMAC-SHA256
    - RSASSA-PKCS1-v1.5-SHA256
    - PLAIN over SSL/TLS

But: which of these are Mandatory-to-Implement?

Issue #2: Include the Normalized Request with the Request?
http://www.ietf.org/mail-archive/web/oauth/current/msg00962.html

Seeming consensus to not include the normalized request (e.g.,
signature string).

Issue #3: Allow Secrets in Cleartext, or Require Channel Encryption?
http://www.ietf.org/mail-archive/web/oauth/current/msg00963.html

Seeming consensus that channel encryption is must-implement (which does
not necessarily mean must-deploy).

Issue #4: Authentication Challenges
http://www.ietf.org/mail-archive/web/oauth/current/msg01039.html

If an authentication (access) request is unacceptable, how does the
server tell the client how it can provide proper credentials (e.g.,
by using a different algorithm)?

Possible other topics:

- Mutual auth?
  http://www.ietf.org/mail-archive/web/oauth/current/msg00935.html

- Resource authorization?
  http://www.ietf.org/mail-archive/web/oauth/current/msg01033.html

******

/psa

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 00:24:46 -0700

Please add:

- Discuss Adobe's recent request to allow excluding the host/port from the signed message.

- With regards to #4, how should the challenge identify the token to be used (realm comes free, do we need another)?

- Should a single token support multiple signature algorithms? This has implications as to the information the client has to include with the request (the algorithm used, etc.).

- Where should the token structure live? OAuth 1.0 includes two response parameters (token and token_secret). However, since we are now moving towards having the algorithm part of the token definition, as well as duration and other attributes, the server will need to provide this information to the client. This calls for a simple schema (can be any format but need to agree to consistent names). It is currently part of the authorization/delegation draft (implicitly), but we should discuss moving it to the authentication draft since that's where it is used (the authorization draft simply hands those "things" out).

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peter Saint-Andre
> Sent: Tuesday, February 02, 2010 9:15 PM
> To: OAuth WG
> Subject: [OAUTH-WG] proposed agenda for second interim meeting
> 
> <hat type='chair'/>
> 
> starting with the topic of authentication. I have reviewed all of the related
> threads on the list and have come up with the following *rough* agenda.
> Your feedback is welcome to improve this (a.k.a. "agenda
> Eran had hoped to push out a new version in time for our meeting, but hasn't
> been able to get to it yet. However, I think we can continue to move forward
> with discussion. Feedback is welcome on the general approach, as well as
> specific open issues.
> 
> Open issues....
> 
> Seeming consensus to not include the normalized request (e.g., signature
> string).
> 
> If an authentication (access) request is unacceptable, how does the server
> tell the client how it can provide proper credentials (e.g., by using a different
> algorithm)?
> 
> Possible other topics:
> 
> - Mutual auth?

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Feb 2010 07:01:48 -0800

Hi Eran

I think it is a little early in our phone discussions to get into technical details. The next step according to the last call was to gather and review use cases. Without rough consensus on what problem we are solving, your points below (which all do need to be discussed at some point) is just moving around deck chairs on the Titanic.

-- Dick

On 2010-02-02, at 11:24 PM, Eran Hammer-Lahav wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 09:40:55 -0700

Has anyone gathered and reviewed use cases? I haven't seen much of that showing up on the list. From my experience, asking people for use cases rarely works, unless someone is willing to do the work and collect them (and so far I haven't heard from such volunteer). I much prefer the process in which we produce a technical document based on OAuth 1.0 and the new requirements as defined by WRAP, and discuss use cases as a property of the technical attributes of this draft.

Of course, you don't have to agree with me, but that puts the burden of producing use cases documentation on you and others interested in taking that approach. We certainly have room for both, and keep in mind that my token draft is not (yet) a working group item.

The indication I received from many of the active members of this list is that we have a strong desire to show up at Anaheim with two stable drafts. I think we are very close to getting the authentication piece done following much of OAuth 1.0 functionality (only cleaner and better structures), as well as treating bearer tokens as first class citizens. Given that no one has started a discussion about the delegation flows to include, I doubt we will have a stable second draft, but I plan on getting the authentication piece stable in time.

It has also been my experience over the past two years that the biggest challenge is to figure out the authentication piece. The 'go get a token' piece tends to be much easier to agree on. If we get the authentication draft to a stable place, my intention is to leave it there and focus on the second part and come back to it as the delegation requirements become clearer (if changes are needed). But at least it gives us something stable to build upon.

EHL

> From: Dick Hardt [mailto:[email-masked]]
> Sent: Wednesday, February 03, 2010 7:02 AM
> To: Eran Hammer-Lahav
> Cc: Peter Saint-Andre; OAuth WG
> Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting
> 
> Hi Eran
> 
> I think it is a little early in our phone discussions to get into technical details.
> The next step according to the last call was to gather and review use cases.
> Without rough consensus on what problem we are solving, your points
> below (which all do need to be discussed at some point) is just moving
> around deck chairs on the Titanic.
> 
> -- Dick
> 
> > - With regards to #4, how should the challenge identify the token to be
> used (realm comes free, do we need another)?
> >
> > - Should a single token support multiple signature algorithms? This has
> implications as to the information the client has to include with the request
> (the algorithm used, etc.).
> >
> > - Where should the token structure live? OAuth 1.0 includes two response
> parameters (token and token_secret). However, since we are now moving
> towards having the algorithm part of the token definition, as well as duration
> and other attributes, the server will need to provide this information to the
> client. This calls for a simple schema (can be any format but need to agree to
> consistent names). It is currently part of the authorization/delegation draft
> (implicitly), but we should discuss moving it to the authentication draft since
> that's where it is used (the authorization draft simply hands those "things"
> out).
> >
> > EHL
> >
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Peter Saint-Andre
> >> Therefore I propose that this time we focus on some unfinished
> >> business, starting with the topic of authentication. I have reviewed
> >> all of the related threads on the list and have come up with the following
> *rough* agenda.
> >> hasn't been able to get to it yet. However, I think we can continue
> >> to move forward with discussion. Feedback is welcome on the general
> >> Seeming consensus that channel encryption is must-implement (which
> >> does not necessarily mean must-deploy).
> >>

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 3 Feb 2010 17:01:38 +0000

I would tend to agree with Dick based upon the last call and where that was heading. I believe that Eve had some use cases to share around UMA

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Wednesday, February 03, 2010 8:41 AM
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting

EHL

> > - Discuss Adobe's recent request to allow excluding the host/port 
> > from the
> signed message.
> >
> implications as to the information the client has to include with the 
> request (the algorithm used, etc.).
> >
> towards having the algorithm part of the token definition, as well as 
> duration and other attributes, the server will need to provide this 
> information to the client. This calls for a simple schema (can be any 
> format but need to agree to consistent names). It is currently part of 
> the authorization/delegation draft (implicitly), but we should discuss 
> moving it to the authentication draft since that's where it is used (the authorization draft simply hands those "things"
> out).
> >
> > EHL
> >
> >> business, starting with the topic of authentication. I have 
> >> reviewed all of the related threads on the list and have come up 
> >> with the following
> *rough* agenda.
> >> Eran had hoped to push out a new version in time for our meeting, 
> >> but hasn't been able to get to it yet. However, I think we can 
> >> continue to move forward with discussion. Feedback is welcome on 
> >> the general approach, as well as specific open issues.
> >>
> >> Open issues....
> >>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 10:34:07 -0700

Hi Anthony,

The problem with this approach is that it hasn't worked (multiple times) before because no one ever wants to do the work of collecting and writing the use cases. What we get instead are short cryptic lists and pointers to edge cases. We have a good grasp on how OAuth 1.0 is used and its limitations as addressed by the WRAP draft.

The best use of my time is to continue working on the drafts and asking technical questions whenever a decision is needed. If and when someone writes use cases, I will review those and see if they are supported by the drafts.
 
I will leave it up to the chairs to decide how they want to guide the working group.

EHL

> From: Anthony Nadalin [mailto:[email-masked]]
> Sent: Wednesday, February 03, 2010 9:02 AM
> To: Eran Hammer-Lahav; Dick Hardt
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] proposed agenda for second interim meeting
> 
> I would tend to agree with Dick based upon the last call and where that was
> heading. I believe that Eve had some use cases to share around UMA
> 
> Of Eran Hammer-Lahav
> Has anyone gathered and reviewed use cases? I haven't seen much of that
> showing up on the list. From my experience, asking people for use cases
> rarely works, unless someone is willing to do the work and collect them (and
> so far I haven't heard from such volunteer). I much prefer the process in
> which we produce a technical document based on OAuth 1.0 and the new
> requirements as defined by WRAP, and discuss use cases as a property of the
> technical attributes of this draft.
> 
> Of course, you don't have to agree with me, but that puts the burden of
> producing use cases documentation on you and others interested in taking
> that approach. We certainly have room for both, and keep in mind that my
> token draft is not (yet) a working group item.
> 
> The indication I received from many of the active members of this list is that
> we have a strong desire to show up at Anaheim with two stable drafts. I think
> we are very close to getting the authentication piece done following much of
> OAuth 1.0 functionality (only cleaner and better structures), as well as
> treating bearer tokens as first class citizens. Given that no one has started a
> discussion about the delegation flows to include, I doubt we will have a
> stable second draft, but I plan on getting the authentication piece stable in
> time.
> 
> It has also been my experience over the past two years that the biggest
> challenge is to figure out the authentication piece. The 'go get a token' piece
> tends to be much easier to agree on. If we get the authentication draft to a
> stable place, my intention is to leave it there and focus on the second part
> and come back to it as the delegation requirements become clearer (if
> changes are needed). But at least it gives us something stable to build upon.
> 
> EHL
> 
> > moving it to the authentication draft since that's where it is used (the
> authorization draft simply hands those "things"
> > out).
> > >
> > > EHL
> > >

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Feb 2010 09:43:23 -0800

Eran, 

Both Tony and I are explaining to you what happened on the call. If you had been on the call, you could have presented your view on how to proceed with the calls. 
While you may have a different opinion on how to proceed (which I am NOT arguing with), arguing with us on what happened on the call seems pointless.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 10:59:36 -0700

I read the minutes.

I don't need to be on the call to present my views on how to proceed. That's not how the IETF operates. I have been expressing my views for the past year, right here on the list. I didn't see any consensus call from the chairs about taking this approach (instead of others).

I also noticed the lack of follow up since the call with any kind of discussion on use cases.

I have asked the chairs to provide a place to discuss technical issues and that is what this second call is about. Unless the chairs decide to change it.

EHL

> Sent: Wednesday, February 03, 2010 9:43 AM
> To: Eran Hammer-Lahav
> Cc: Anthony Nadalin; OAuth WG
> Both Tony and I are explaining to you what happened on the call. If you had
> been on the call, you could have presented your view on how to proceed
> with the calls.
> While you may have a different opinion on how to proceed (which I am NOT
> arguing with), arguing with us on what happened on the call seems pointless.
> 
> -- Dick
> 
> > The problem with this approach is that it hasn't worked (multiple times)
> before because no one ever wants to do the work of collecting and writing
> the use cases. What we get instead are short cryptic lists and pointers to
> edge cases. We have a good grasp on how OAuth 1.0 is used and its
> limitations as addressed by the WRAP draft.
> >
> > The best use of my time is to continue working on the drafts and asking
> technical questions whenever a decision is needed. If and when someone
> writes use cases, I will review those and see if they are supported by the
> drafts.
> >
> >> I would tend to agree with Dick based upon the last call and where
> >> that was heading. I believe that Eve had some use cases to share
> >> around UMA
> >>
> >> Behalf Of Eran Hammer-Lahav
> >> Has anyone gathered and reviewed use cases? I haven't seen much of
> >> that showing up on the list. From my experience, asking people for
> >> use cases rarely works, unless someone is willing to do the work and
> >> collect them (and so far I haven't heard from such volunteer). I much
> >> prefer the process in which we produce a technical document based on
> >> OAuth 1.0 and the new requirements as defined by WRAP, and discuss
> >> use cases as a property of the technical attributes of this draft.
> >>
> >> Of course, you don't have to agree with me, but that puts the burden
> >> of producing use cases documentation on you and others interested in
> >> taking that approach. We certainly have room for both, and keep in
> >> mind that my token draft is not (yet) a working group item.
> >>
> >> The indication I received from many of the active members of this
> >> list is that we have a strong desire to show up at Anaheim with two
> >> stable drafts. I think we are very close to getting the
> >> authentication piece done following much of OAuth 1.0 functionality
> >> (only cleaner and better structures), as well as treating bearer
> >> tokens as first class citizens. Given that no one has started a
> >> discussion about the delegation flows to include, I doubt we will
> >> have a stable second draft, but I plan on getting the authentication piece
> stable in time.
> >>
> >> It has also been my experience over the past two years that the
> >> biggest challenge is to figure out the authentication piece. The 'go
> >> get a token' piece tends to be much easier to agree on. If we get the
> >> authentication draft to a stable place, my intention is to leave it
> >> there and focus on the second part and come back to it as the
> >> delegation requirements become clearer (if changes are needed). But at
> least it gives us something stable to build upon.
> >>
> >> EHL
> >>
> >>> below (which all do need to be discussed at some point) is just
> >>> moving around deck chairs on the Titanic.
> >>>
> >>> -- Dick
> >>>
> >>> implications as to the information the client has to include with
> >>> the request (the algorithm used, etc.).
> >>>>
> >>> parameters (token and token_secret). However, since we are now
> >>> moving towards having the algorithm part of the token definition, as
> >>> well as duration and other attributes, the server will need to
> >>> provide this information to the client. This calls for a simple
> >>> schema (can be any format but need to agree to consistent names). It
> >>> is currently part of the authorization/delegation draft
> >>> (implicitly), but we should discuss moving it to the authentication
> >>> draft since that's where it is used (the
> >>>>> If an authentication (access) request is unacceptable, how does
> >>>>> the server tell the client how it can provide proper credentials
> >>>>> (e.g., by using a different algorithm)?
> >>>>>
> >>>>> Possible other topics:
> >>>>>
> >>>>> - Mutual auth?

---

From: Blaine Cook <[email-masked]>
Date: Wed, 3 Feb 2010 18:15:15 +0000

I've started a wiki page here:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OauthFeatureMatrix

to pull in the features people think are important, and give us both
some way of collecting that data over time and expressing what's
present or missing from each protocol & proposal. Despite being called
FeatureMatrix, please treat it as a Use Case Matrix.

If people don't want to go in and edit the wiki table (I don't blame
you) please send your use cases to me ([email-masked]) and I will
fill them out on the wiki for you. If you have blog posts or links to
pre-existing use cases or features, please include those as they will
help clarify the features.

b.

ps. the wiki won't let me put in a bookmarklet to make the text entry
not suck (i.e., use a fixed-width font), so here's one in case you do
decide to edit the wiki:

javascript:document.getElementById('text').style.fontFamily='courier'

---

From: Eve Maler <[email-masked]>
Date: Wed, 3 Feb 2010 10:54:14 -0800

Sorry for the delay, and thanks for the push.  In scrambling to approve a passel of scenarios and produce our webinar last week, we got a bit behind.  (By the way, complete recordings are now available.  Their quality is not perfect, but should suffice.  Please see http://kantarainitiative.org/confluence/display/uma/UMA+Explained for recordings, overview slides, protocol explanation slides, and example wireframes.)

In order to inform the OAuth V2.0 effort, here is some information about key User-Managed Access (UMA) use cases and needs.  The wiki home is at http://kantarainitiative.org/confluence/display/uma/Home , and the sidebar on the right has links to all the available materials.

The focus of UMA is to externalize authorization decisions currently performed by OAuth SPs/servers into a fourth distinct entity we call an "authorization manager" or AM.  Protected resources are hosted at endpoints called "hosts" and the endpoints seeking data/service access are called "requesters". An application embodying the AM endpoint can help the "authorizing user" globally manage what otherwise might be a complicated authorization picture among all the services accessing and sharing data about her, including letting her dictate policies for access authorization that the AM enforces.  (If you're familiar with classic access management technology, the AM serves as a policy decision point and the hosts are policy enforcement points.)  An AM provides the user with the ability to apply discretionary access controls for his/her resources. 

The extensive information available about UMA includes a Scenarios and Use Cases document:

http://kantarainitiative.org/confluence/display/uma/UMA+Scenarios+and+Use+Cases

Here are summaries of two of the group's approved scenarios.

Calendaring: Online calendars, whose content is volatile, are valuable to share on an ongoing/"feed" basis.  In somewhat the same fashion that people today share online calendars selectively with other people, a user can share a calendar with a vendor for various purposes.  Prior to allowing the access, she might use UMA to require the requester to assure her they will not misuse or further share her information.  Having authorized access to a particular resource, the user can then examine all the connections forged to all her shared resources in similar fashion, from a single console.

Personal Loan: A user applies for a loan online, and the loan application site requires him to provide certain third-party-attested information, such as his salary, bank account, and credit score.  This information is best hosted directly out of the (several) authoritative sites for it, but the user is able to package up references to all of it and point the loan site to the package; the loan site can then become a requester of each relevant resource.  The user can see, from a single place, whether the information has been successfully received, and can keep a record of its access.  (The webinar wireframes show how this packaging might be achieved, along with illustrating other potential parts of the user experience.)

UMA currently solves its use cases, in part, with a composition of three instances of OAuth (along with using XRD metadata and LRDD discovery methods).  The user introduces each host to the AM with so-called "three-legged" (authn plus web delegation) OAuth as a preface to other interactions.  Each requester later dynamically introduces itself to a host with the option of using "two-legged" (authn only) OAuth, and then introduces itself to the AM using two-legged OAuth -- we think of these as "automated self-registration" of the services.  The draft spec can be found here:

http://kantarainitiative.org/confluence/display/uma/UMA+1.0+Core+Protocol

A few key points:

- UMA wants to give users an opportunity, not just to set unilateral policy (how long access is allowed over time, whether the user should be asked for real-time consent in some fashion when access is attempted, and so on), but also to set terms which the requester must meet. This gives users new tools for control, and also enables some interesting high-value use cases, involving requests for access on the basis of third-party-attested claims.

- There is a conceptual similarity between the UMA and WRAP entities, but our analysis so far shows it to be shallow in spots.  For example, WRAP's "protected resource" maps fairly well to an UMA "host" (which may host any number of protected resources), and WRAP's and OAuth's "client"/"consumer" maps to an UMA "requester".  However, it seems that a WRAP authorization server is assumed to be in the same domain as a protected resource, allowing for implicit rather than explicit scoping of resources.  The UMA authorization manager and any one host may be in entirely separate domains, and introductions between them are intended to be user-driven.

	Eve

>> authorization draft simply hands those "things"

Eve Maler
[email-masked]
http://www.xmlgrrl.com/blog

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Feb 2010 10:55:20 -0800

I recall from the call that Peter did ask if there was consensus on the approach of gathering use cases. There seemed consensus that the WG might not fully understand the problem and that this made sense. I don't see that clearly captured in the minutes, hence me communicating to you what had occurred on the call. 

FWIW: II had intended my email to be useful, non-confrontational feedback on your agenda proposal. I am finding your responses to be abrasive. Have I offended you in some way? If you have suggestions for what I can do to be more productive in communicating to you, I would welcome them.

-- Dick

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 12:19:25 -0700

I did not mean my first reply to you to be abrasive or confrontational, despite being told that my work on the drafts is a waste of time ("moving around deck chairs on the Titanic"). I simply disagreed with your view that it is too early to dedicate the next call to technical details. I actually took the time to articulate an alternative way of moving forward that is more consistent with my experience here for the past year.

It was your later comments (educating me about what took place on that call, which assumed I didn't bother to read the minutes or listen to the audio) that I didn't appreciate.

Any consensus call must be made on the list and not just on the call or in a meeting because the list is the only place everyone is guaranteed equal participation. There is nothing more important in the IETF process than consensus calls and I take them very seriously.

EHL

> Sent: Wednesday, February 03, 2010 10:55 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> I recall from the call that Peter did ask if there was consensus on the
> approach of gathering use cases. There seemed consensus that the WG
> might not fully understand the problem and that this made sense. I don't see
> that clearly captured in the minutes, hence me communicating to you what
> had occurred on the call.
> 
> FWIW: II had intended my email to be useful, non-confrontational feedback
> on your agenda proposal. I am finding your responses to be abrasive. Have I
> offended you in some way? If you have suggestions for what I can do to be
> more productive in communicating to you, I would welcome them.
> 
> -- Dick
> 
> 
> > I don't need to be on the call to present my views on how to proceed.
> That's not how the IETF operates. I have been expressing my views for the
> past year, right here on the list. I didn't see any consensus call from the chairs
> about taking this approach (instead of others).
> >
> > I have asked the chairs to provide a place to discuss technical issues and
> that is what this second call is about. Unless the chairs decide to change it.
> >
> > EHL
> >
> >> Both Tony and I are explaining to you what happened on the call. If
> >> you had been on the call, you could have presented your view on how
> >> to proceed with the calls.
> >> While you may have a different opinion on how to proceed (which I am
> >> NOT arguing with), arguing with us on what happened on the call seems
> pointless.
> >>
> >> -- Dick
> >>
> >> before because no one ever wants to do the work of collecting and
> >> writing the use cases. What we get instead are short cryptic lists
> >> and pointers to edge cases. We have a good grasp on how OAuth 1.0 is
> >> used and its limitations as addressed by the WRAP draft.
> >>>
> >> technical questions whenever a decision is needed. If and when
> >> someone writes use cases, I will review those and see if they are
> >> supported by the drafts.
> >>>
> >>> I will leave it up to the chairs to decide how they want to guide
> >>> the working
> >> group.
> >>>
> >>> EHL
> >>>
> >>>> use cases rarely works, unless someone is willing to do the work
> >>>> and collect them (and so far I haven't heard from such volunteer).
> >>>> I much prefer the process in which we produce a technical document
> >>>> based on OAuth 1.0 and the new requirements as defined by WRAP,
> and
> >>>> discuss use cases as a property of the technical attributes of this draft.
> >>>>
> >>>> Of course, you don't have to agree with me, but that puts the
> >>>> burden of producing use cases documentation on you and others
> >>>> interested in taking that approach. We certainly have room for
> >>>> both, and keep in mind that my token draft is not (yet) a working group
> item.
> >>>>
> >>>> biggest challenge is to figure out the authentication piece. The
> >>>> 'go get a token' piece tends to be much easier to agree on. If we
> >>>> get the authentication draft to a stable place, my intention is to
> >>>> leave it there and focus on the second part and come back to it as
> >>>> the delegation requirements become clearer (if changes are needed).
> >>>> But at
> >>>>> I think it is a little early in our phone discussions to get into
> >>>>> technical
> >> details.
> >>>>> The next step according to the last call was to gather and review
> >>>>> use
> >> cases.
> >>>>> Without rough consensus on what problem we are solving, your
> >>>>> points below (which all do need to be discussed at some point) is
> >>>>> just moving around deck chairs on the Titanic.
> >>>>>
> >>>>> -- Dick
> >>>>>
> >>>>> moving towards having the algorithm part of the token definition,
> >>>>> as well as duration and other attributes, the server will need to
> >>>>> schema (can be any format but need to agree to consistent names).
> >>>>> It is currently part of the authorization/delegation draft
> >>>>> (implicitly), but we should discuss moving it to the
> >>>>> authentication draft since that's where it is used (the
> >>>>>>> Eran had hoped to push out a new version in time for our
> >>>>>>> meeting, but hasn't been able to get to it yet. However, I think
> >>>>>>> we can continue to move forward with discussion. Feedback is
> >>>>>>> welcome on the general approach, as well as specific open issues.
> >>>>>>>
> >>>>>>> Open issues....
> >>>>>>>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 3 Feb 2010 12:21:41 -0700

> Sent: Wednesday, February 03, 2010 11:19 AM
> To: Dick Hardt
> Cc: OAuth WG
> I did not mean my first reply to you to be abrasive or confrontational

INSERT: and I apologize if it came off that way.

EHL

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Feb 2010 11:46:07 -0800

On 2010-02-03, at 11:19 AM, Eran Hammer-Lahav wrote:

> I did not mean my first reply to you to be abrasive or confrontational, despite being told that my work on the drafts is a waste of time ("moving around deck chairs on the Titanic").

I and many others appreciate your work. That was not my intent. Wanting to discuss technical details when there does not seem to be consensus on the problem we are solving was my Titanic reference.

> Any consensus call must be made on the list and not just on the call or in a meeting because the list is the only place everyone is guaranteed equal participation. There is nothing more important i…

Thanks for the clarification.

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Feb 2010 11:46:12 -0800

> INSERT: and I apologize if it came off that way.

Thanks. All good on my side.

-- Dick

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Feb 2010 13:01:05 -0700

<hat type='chair'/>

On 2/3/10 12:46 PM, Dick Hardt wrote:

> Wanting to discuss technical details when there does not seem to be
> consensus on the problem we are solving was my Titanic reference.

We have two dangers here:

1. The Scylla of designing technologies before we fully understand the
problem space and its associated requirements.

2. The Charybdis of discussing the problem space and its associated
requirements but never designing any technologies.

We are attempting to steer a safe course between these two dangers.
Although I tend to the side of those who fear Scylla more than
Charybdis, in my opinion (not consensus that I am declaring as co-chair)
we have enough sense of the problem space regarding authentication that
we can at least have a productive discussion about
draft-ietf-oauth-authentication-01 at tomorrow's interim meeting.
However, in parallel I think we need to keep sifting through various use
cases, and Blaine's stub of a feature matrix is a good first step that
needs more attention before the interim meeting we'll hold two weeks
from tomorrow (February 18). Remember, these interim meetings are
intended to air open issues and get us closer to agreement on problems,
terminology, architecture, use cases, requirements, and possible
technical solutions, all as a way of preparing for the in-person meeting
in Anaheim. IMHO we need to keep working in several directions at once,
so let's keep building out our wiki pages and updating the relevant
Internet-Drafts and sifting through use cases and working through open
issues on this list. Perhaps that's not a perfect process, but I think
it's the best we can do for now. If you disagree, feel free to do so on
list or off. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dick Hardt <[email-masked]>
Date: Wed, 3 Feb 2010 14:26:47 -0800

On 2010-02-03, at 12:01 PM, Peter Saint-Andre wrote:

>  Remember, these interim meetings are
> in Anaheim.

That was what I thought the calls were for, which is why I did not think Eran's desire to add discussion of a specific technical issue was going to be well received. There are a number of us that are new to the WG and we likely will make little progress until we are all relatively on the same page on what problem(s) we are solving. I certainly hope we don't need to spend much time on these topics, but some time will be invaluable in my opinion.

Speaking for myself, I am still confused why the spec has been broken into two parts and what is intended in the Authentication document. I am just now starting to try and grok what the UMA people want to solve.

-- Dick

---

From: "Vrancken Bart bv" <[email-masked]>
Date: Thu, 4 Feb 2010 10:39:11 +0100

Hi folks,

In the beginning of December, I posted 2 use cases for multi-level
delegation, but I didn't receive a lot of feedback there:
http://www.ietf.org/mail-archive/web/oauth/current/msg00807.html

Please feel free to provide feedback, now we are discussing about use
cases.

Best regards,

Bart Vrancken

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Eran Hammer-Lahav
Sent: woensdag 3 februari 2010 17:41
To: Dick Hardt
Cc: OAuth WG
Subject: Re: [OAUTH-WG] proposed agenda for second interim meeting

Has anyone gathered and reviewed use cases? I haven't seen much of that
showing up on the list. From my experience, asking people for use cases
rarely works, unless someone is willing to do the work and collect them
(and so far I haven't heard from such volunteer). I much prefer the
process in which we produce a technical document based on OAuth 1.0 and
the new requirements as defined by WRAP, and discuss use cases as a
property of the technical attributes of this draft.

The indication I received from many of the active members of this list
is that we have a strong desire to show up at Anaheim with two stable
drafts. I think we are very close to getting the authentication piece
done following much of OAuth 1.0 functionality (only cleaner and better
structures), as well as treating bearer tokens as first class citizens.
Given that no one has started a discussion about the delegation flows to
include, I doubt we will have a stable second draft, but I plan on
getting the authentication piece stable in time.

It has also been my experience over the past two years that the biggest
challenge is to figure out the authentication piece. The 'go get a
token' piece tends to be much easier to agree on. If we get the
authentication draft to a stable place, my intention is to leave it
there and focus on the second part and come back to it as the delegation
requirements become clearer (if changes are needed). But at least it
gives us something stable to build upon.

EHL

> I think it is a little early in our phone discussions to get into
technical details.
from the
> implications as to the information the client has to include with the
request
> towards having the algorithm part of the token definition, as well as
duration
> (implicitly), but we should discuss moving it to the authentication
draft since
> >> business, starting with the topic of authentication. I have
reviewed
> >> Eran had hoped to push out a new version in time for our meeting,
but

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Feb 2010 10:45:40 -0800

> - There is a conceptual similarity between the UMA and WRAP entities, but our analysis so far shows it to be shallow in spots.  For example, WRAP's "protected resource" maps fairly well to an UMA "…

In OAuth WRAP,  Authorization Server (AS) is NOT assumed to be in the same domain as the Protected Resource (PR). The Client does need to know which AS it can call for an Access Token for a given PR. Discovery of the PR and AS was out of scope for OAuth WRAP (and I think for this WG). We figured general purpose APIs would have their own discovery and the AS and PR would be discovered in that process.

-- Dick

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 04 Feb 2010 11:47:20 -0700

<hat type='chair'/>

On 2/3/10 11:55 AM, Dick Hardt wrote:
> I recall from the call that Peter did ask if there was consensus on
> the approach of gathering use cases. There seemed consensus that the
> WG might not fully understand the problem and that this made sense.

I agree, but given that we haven't had a lot of discussion about use
cases on the list, I figured it would be more productive to focus this
call on the authentication work, encourage more people to contribute use
cases over the next two weeks, and then discuss use cases on the next
call (slated for February 11, I need to schedule that today).

Peter

---

From: Dick Hardt <[email-masked]>
Date: Thu, 4 Feb 2010 10:52:27 -0800

> call (slated for February 11, I need to schedule that today).

Works for me. 

I'm hopeful someone can explain what is meant by "authentication work"!

From my understanding of Eran's draft, I don't see the distinction between Authorization Server and Protected Resource we have in OAuth WRAP.

-- Dick

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 04 Feb 2010 11:54:35 -0700

On 2/4/10 11:52 AM, Dick Hardt wrote:
>>> I recall from the call that Peter did ask if there was consensus
>>> on the approach of gathering use cases. There seemed consensus
>>> that the WG might not fully understand the problem and that this
>>> made sense.
>> 
>> I agree, but given that we haven't had a lot of discussion about
>> use cases on the list, I figured it would be more productive to
>> focus this call on the authentication work, encourage more people
>> to contribute use cases over the next two weeks, and then discuss
>> use cases on the next call (slated for February 11, I need to
>> schedule that today).
> 
> Works for me.
> 
> From my understanding of Eran's draft, I don't see the distinction
> between Authorization Server and Protected Resource we have in OAuth
> WRAP.

By "Eran's draft" do you mean draft-ietf-oauth-authentication-01 or
draft-hammer-http-token-auth-01?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 4 Feb 2010 19:17:42 +0000

> use UMA to require the requester to assure her they will not misuse or further share her information

Not sure how UMA would be able to deal with this, if you look at things like the OECD Data Protection Principles (on which Privacy laws have been based) there are a lot of things considered misuse

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eve Maler
Sent: Wednesday, February 03, 2010 10:54 AM
To: OAuth WG
Subject: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second interim meeting)

A few key points:

	Eve

On 3 Feb 2010, at 9:34 AM, Eran Hammer-Lahav wrote:

>> have a stable second draft, but I plan on getting the authentication piece stable in time.
>> 
>> delegation requirements become clearer (if changes are needed). But at least it gives us something stable to build upon.
>> 
>> EHL
>> 

Eve Maler
[email-masked]

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 04 Feb 2010 16:12:40 -0500

I think it is worth a detailed discussion to conclude whether or not 
UMA addresses the OECD principles. I don't have an opinion, and I don't 
know OECD well enough to have one, but I think it is important, and I am 
glad that Anthony has brought this up.

Igor

---

From: "Paul C. Bryan" <[email-masked]>
Date: Thu, 04 Feb 2010 14:37:36 -0800

On Thu, 2010-02-04 at 19:17 +0000, Anthony Nadalin wrote:
> Not sure how UMA would be able to deal with this, if you look at
> things like the OECD Data Protection Principles (on which Privacy laws
> have been based) there are a lot of things considered misuse

I don't imagine there would be any such term called "misuse" that a
requester would claim. There would be specific, possibly enforceable
terms. Examples:

1. Requester will retain accessed information for no longer than {n}
days.

2. Requester will not share accessed information with any third party
except as required to comply with the laws of {region, ...}.

Paul

> Of Eve Maler
> Sorry for the delay, and thanks for the push.  In scrambling to
> approve a passel of scenarios and produce our webinar last week, we
> got a bit behind.  (By the way, complete recordings are now available.
> Their quality is not perfect, but should suffice.  Please see
> http://kantarainitiative.org/confluence/display/uma/UMA+Explained for
> recordings, overview slides, protocol explanation slides, and example
> wireframes.)
> 
> In order to inform the OAuth V2.0 effort, here is some information
> about key User-Managed Access (UMA) use cases and needs.  The wiki
> home is at http://kantarainitiative.org/confluence/display/uma/Home ,
> and the sidebar on the right has links to all the available materials.
> 
> The focus of UMA is to externalize authorization decisions currently
> performed by OAuth SPs/servers into a fourth distinct entity we call
> an "authorization manager" or AM.  Protected resources are hosted at
> endpoints called "hosts" and the endpoints seeking data/service access
> are called "requesters". An application embodying the AM endpoint can
> help the "authorizing user" globally manage what otherwise might be a
> complicated authorization picture among all the services accessing and
> sharing data about her, including letting her dictate policies for
> access authorization that the AM enforces.  (If you're familiar with
> classic access management technology, the AM serves as a policy
> decision point and the hosts are policy enforcement points.)  An AM
> provides the user with the ability to apply discretionary access
> controls for his/her resources. 
> 
> Calendaring: Online calendars, whose content is volatile, are valuable
> to share on an ongoing/"feed" basis.  In somewhat the same fashion
> that people today share online calendars selectively with other
> people, a user can share a calendar with a vendor for various
> purposes.  Prior to allowing the access, she might use UMA to require
> the requester to assure her they will not misuse or further share her
> information.  Having authorized access to a particular resource, the
> user can then examine all the connections forged to all her shared
> resources in similar fashion, from a single console.
> 
> Personal Loan: A user applies for a loan online, and the loan
> application site requires him to provide certain third-party-attested
> information, such as his salary, bank account, and credit score.  This
> information is best hosted directly out of the (several) authoritative
> sites for it, but the user is able to package up references to all of
> it and point the loan site to the package; the loan site can then
> become a requester of each relevant resource.  The user can see, from
> a single place, whether the information has been successfully
> received, and can keep a record of its access.  (The webinar
> wireframes show how this packaging might be achieved, along with
> illustrating other potential parts of the user experience.)
> 
> UMA currently solves its use cases, in part, with a composition of
> three instances of OAuth (along with using XRD metadata and LRDD
> discovery methods).  The user introduces each host to the AM with
> so-called "three-legged" (authn plus web delegation) OAuth as a
> preface to other interactions.  Each requester later dynamically
> introduces itself to a host with the option of using
> "two-legged" (authn only) OAuth, and then introduces itself to the AM
> using two-legged OAuth -- we think of these as "automated
> self-registration" of the services.  The draft spec can be found here:
> 
> - UMA wants to give users an opportunity, not just to set unilateral
> policy (how long access is allowed over time, whether the user should
> be asked for real-time consent in some fashion when access is
> attempted, and so on), but also to set terms which the requester must
> meet. This gives users new tools for control, and also enables some
> interesting high-value use cases, involving requests for access on the
> basis of third-party-attested claims.
> 
> - There is a conceptual similarity between the UMA and WRAP entities,
> but our analysis so far shows it to be shallow in spots.  For example,
> WRAP's "protected resource" maps fairly well to an UMA "host" (which
> may host any number of protected resources), and WRAP's and OAuth's
> "client"/"consumer" maps to an UMA "requester".  However, it seems
> that a WRAP authorization server is assumed to be in the same domain
> as a protected resource, allowing for implicit rather than explicit
> scoping of resources.  The UMA authorization manager and any one host
> may be in entirely separate domains, and introductions between them
> are intended to be user-driven.
> 
> 	Eve
> 
> > The problem with this approach is that it hasn't worked (multiple
> times) before because no one ever wants to do the work of collecting
> and writing the use cases. What we get instead are short cryptic lists
> > The best use of my time is to continue working on the drafts and
> asking technical questions whenever a decision is needed. If and when
> the working group.
> burden 
> 'go 
> >> delegation requirements become clearer (if changes are needed). But
> at least it gives us something stable to build upon.
> >> 
> >> EHL
> >> 
> use cases.
> points 
> >>>> - With regards to #4, how should the challenge identify the
> token 
> >>>> to be
> >>>> - Should a single token support multiple signature algorithms?
> This 
> >>>> has
> as 
> It

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 4 Feb 2010 23:06:30 +0000

Agree on the measurable/enforceable items

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul C. Bryan
Sent: Thursday, February 04, 2010 2:38 PM
To: OAuth WG
Subject: Re: [OAUTH-WG] UMA use cases (was Re: proposed agenda for second interim meeting)

> have been based) there are a lot of things considered misuse

I don't imagine there would be any such term called "misuse" that a requester would claim. There would be specific, possibly enforceable terms. Examples:

1. Requester will retain accessed information for no longer than {n} days.

2. Requester will not share accessed information with any third party except as required to comply with the laws of {region, ...}.

Paul

> introduces itself to a host with the option of using "two-legged" 
> (authn only) OAuth, and then introduces itself to the AM using 
> two-legged OAuth -- we think of these as "automated self-registration" 
> of the services.  The draft spec can be found here:
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 4 Feb 2010 16:26:50 -0700

All these items are still open for discussion, even if we didn't get to them on the call.

EHL

> Sent: Tuesday, February 02, 2010 11:25 PM
> To: Peter Saint-Andre; OAuth WG
> > server tell the client how it can provide proper credentials (e.g., by
> > using a different algorithm)?
> >
> > Possible other topics:
> >
> > - Mutual auth?

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 04 Feb 2010 16:39:44 -0700

Indeed. Feel free to start separate threads on each, add them to the
issue tracker, etc. I'll be mostly offline (travelling) for the next 36
hours but will try to catch up then.

Thanks to everyone who participated in today's call.