On 7/9/10 7:30 PM, Hannes Tschofenig wrote:

Hi Hannes,

> sorry for the late response.

np

>
> Interesting statement.
>
> I agree that there are other approaches (and probably everyone would
> agree with that; we could even list Kerberos).
>
> However, the MOONSHOT BOF is (if I understood it correctly)
> constraint to the mentioned constraints.

hmm, afaik it is a federated authentication BoF, not a Moonshot BoF

>
> The usage of OpenID in SASL/GSS-API (like you pointed out) will be
> done in KITTEN independently and has different design constraints.

I think there is a bit of misunderstanding, I gave those just as an 
example because I happen to be familiar with them. I am happy with those 
drafts being in KITTEN, if only to speed things up. So that is not the 
point.

My point is that I'd like the BoF to start open-minded. I believe 
federated authentication for non-Web is a large and interesting area. I 
would like to make sure that we don't rule out beforehand alternative 
approaches. I am happy with a charter as outcome that specifies that the 
WG is going to take the Moonshot approach, but imo that should be the 
*result* of the BoF, not a *precondition*.

Hope this clarifies the misunderstanding.

Klaas

>
> Ciao Hannes
>
>> On 7/6/10 11:15 AM, Hannes Tschofenig wrote:
>>
>> Hi Hannes,
>>
>>> at the next IETF meeting we are going to have a BOF about
>>> "Federated
>> Authentication Beyond The Web". In case you have not noticed the
>> work relates to RADIUS and Diameter.
>>>
>>> I wrote this very short problem statement document to explain
>>> the
>> purpose of the BOF:
>>> http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt
>>>
>>>
>>>
Let me know if you find the description useful. Feedback about the BOF
>> topic would also be appreciated.
>>
>> I find the description useful, however I would like to challenge
>> the MUST for RADIUS and/or Diamter. There are a number of
>> Federated Authentication for applications access protocols out
>> there, SAML, OpenID and others. RADIUS and Diamter are typically
>> associated with network access. And while I do see the
>> attractiveness of marrying the two (and thus leveraging existing
>> trust fabrics), I wonder why you want to restrict a priori to just
>> those. As an example draft-cantor-ietf-sasl-saml-ec-00.txt,
>> draft-lear-ietf-sasl-openid-00, and
>> draft-wierenga-ietf-sasl-saml-00 specify the use of federated
>> authentication in a SASL context. And services like eduroam are an
>> example of the use of just RADIUS to implement federated
>> authentication for non-web applications. I do understand that it is
>> not possible nor desirable to take on everything, but let's at
>> least have this scoping discussion in the BoF.
>>
>> Klaas
>>
>> -- to unsubscribe send a message to [log in to unmask]
>> with the word 'unsubscribe' in a single line as the message text
>> body. archive:<http://psg.com/lists/radiusext/>