Re: [oauth] OAUTH Charter Proposal

[Hubert Le Van Gong <[e-mail]>]

Hi Hannes,

Thanks for the clarification; I understand what was meant.
I would note however that this paragraph mixes 2 distinct
issues: backward compatibility and interoperability.
We want to promote both but not necessarily at the
expense of one of them (and security as well).
For instance, it is recommended that at least one security
algorithm is made mandatory. If we mandate backward
compatibility then that algorithm can only be one of the
algorithms already defined in OAuth 1.0 which, as noted
in older email threads, is not a good idea.
IMHO ensuring interoperability & good security of the
to-be IETF spec is, in fine, paramount to ensuring
100% backward compatibility (of course a solution
could be to mandate at least 2 security algos, one from
the 1.0 spec and another more future-proof).

These considerations may not need to appear in
the charter but I think it is important to be as clear
as possible on the intent of the charter.

Cheers,
Hubert



>>"It seems desireable to profile OAuth 1.0 in a way that
>>produces a specification that is a backwards compatible
>>profile, i.e. any OAUTH 1.0 and the specification produced by
>>this group must support a basic set of features to guarantee
>>interoperability."
>>
>>- Profiling usually means to constrain further an existing
>>specification.
>>  This seems to contradict the part of the charter that talks of
>>  supporting broader use cases beyond the original scope...?
>>  What did you mean there?
>
> When multiple options are provided then indicating which onces are mandatory
> to implement is something that I call profiling. When the profiled version
> is run against Oauth 1.0 it would still interoperate (in some sense; if that
> particular Oauth 1.0 implementation had implemented all options). You
> mention this aspect of improving interoperability in your next paragraph
> below as well.
>
> The sentence about "Ability to address broader use cases than may be
> contemplated by the original authors" can be more seen as a "we leave room
> for extensions that offer additional use cases" phrase.
>
>>- I would argue that there is no guaranteed interoperability in the
>>  current OAuth 1.0 spec. We need to address this. The security report
>>  Sam (Hartman) created highlights a few things that should
>>  be done:
>>  (1) mandatory-to-implement algorithm(s) for security
>>  (2) interoperable way to find the lifetime of a request or
>>      access-token
>>  (3) description of how a service uses OAuth
>
> These things sound good to me. I guess you don't want to list them in the
> charter itself, right?
>
> Ciao
> Hannes
>
>>
>>I had the same comment as George just sent on AuthZ vs. AuthN
>>
>>Cheers,
>>Hubert
>>
>>
>>
>>On Fri, Jan 30, 2009 at 6:55 PM, Hannes Tschofenig
>><[e-mail]> wrote:
>>> Hi all,
>>>
>>> After a chat with Lisa I got in touch with Eran to slightly
>>revise the
>>> charter text that Sam and Mark put together for the last
>>IETF meeting.
>>>
>>> It should addresses some of the comments provided during the
>>BOF. Your
>>> feedback is welcome.
>>>
>>> Ciao
>>> Hannes
>>>
>>> -------------------------------------
>>>
>>> Open Authentication Protocol (oauth)
>>>
>>> Last Modified: 2009-01-30
>>>
>>> Chair(s):
>>>
>>> TBD
>>>
>>> Applications Area Director(s):
>>>
>>> Chris Newman <[e-mail]>
>>> Lisa Dusseault <[e-mail]>
>>>
>>> Applications Area Advisor:
>>>
>>> TBD
>>>
>>> Mailing Lists:
>>>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> Description of Working Group:
>>>
>>> OAuth allows a user to grant a third-party Web site or application
>>> access to their resources, without revealing their credentials, or
>>> even their identity. For example, a photo-sharing site that supports
>>> OAuth would allow its users to use a third-party printing
>>Web site to
>>> access their private pictures, without gaining full control
>>of the user account.
>>>
>>> OAuth consist of:
>>>  * A mechanism for exchanging a user's credentials for a
>>token-secret
>>> pair which can be used by a third party to access resources on their
>>> behalf
>>>  * A mechanism for signing HTTP requests with the token-secret pair
>>>
>>> The Working Group will produce one or more documents suitable for
>>> consideration as Proposed Standard, based upon the OAuth
>>I-D, that will:
>>>  * Align OAuth with the Internet and Web architectures, best
>>practices
>>> and terminology
>>>  * Assure good security practice, or document gaps in its
>>capabilities
>>>  * Promote interoperability
>>>
>>> This specifically means that as a starting point for the
>>working group
>>> the OAuth 1.0 specification is used and the available
>>extension points
>>> are going to be utilized. It seems desireable to profile
>>OAuth 1.0 in
>>> a way that produces a specification that is a backwards compatible
>>> profile, i.e. any OAUTH 1.0 and the specification produced by this
>>> group must support a basic set of features to guarantee
>>> interoperability.
>>>
>>> Furthermore, Oauth 1.0 defines three signature methods used
>>to protect
>>> requests, namely PLAINTEXT, HMAC-SHA1, and RSA-SHA1. The group will
>>> work on new signature methods in case the existing mechanisms do not
>>> fulfill the security requirements. Existing signature
>>methods will not
>>> be modified but may be dropped as part of the backwards
>>compatible profiling activity.
>>>
>>> In doing so, it should consider:
>>>  * Implementer experience
>>>  * Existing uses of OAuth
>>>  * Ability to achieve broad impementation
>>>  * Ability to address broader use cases than may be contemplated by
>>> the original authors
>>>  * Impact on the Internet and Web
>>>
>>> The Working Group is not tasked with defining a generally applicable
>>> HTTP Authentication mechanism (i.e., browser-based "2-leg"
>>scenerio),
>>> and should consider this work out of scope in its discussions.
>>> However, if the deliverables are able to be factored in such a way
>>> that this is a byproduct, or such a scenario could be addressed by
>>> additional future work, the Working Group may choose to do so.
>>>
>>> After delivering OAuth, the Working Group MAY consider defining
>>> additional functions and/or extensions, for example (but not limited
>>> to):
>>>  * Discovery of authentication configuration
>>>  * Message integrity
>>>  * Recommendations regarding the structure of the token
>>>
>>> Goals and Milestones:
>>>
>>> 12/2009     Submit document(s) suitable for publication as
>>standards-track
>>> RFCs.
>>>
>>> _______________________________________________
>>> oauth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>
>
_______________________________________________
oauth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth