<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


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

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

Reply via email to