Anothny -
Please see embedded responses below, prefixed with
[jm].
---------
Jahan Moreh
Chief Security
Architect
310.286.3070
-----Original Message-----
From: Anthony
Nadalin [mailto:]
Sent:
Tuesday, October 14, 2003 11:56 AM
To:
Subject: Re: [security-services]
Groups -
sstc-saml-MetadataDiscoveryProtocols-2.0-draft-00.pdf
uploaded
Jahan,
Couple of
questions:
(1) Why include the DNS proposal, what is
the motivation, scenarios driving
this to be included ? Will anyone implement
?
[jm] First, please note that this
is optional and not required. The motivation is to tie metadata location
discovery with a known discovery protocol and repository such as DNS. I
personally think it makes sense. Will anyone implement? I certainly cannot
answer this question.
(2) How does one find out
the "well known URL" ? Do I assume that the URL
may not be the resource but
may inquire against something else ? Are there
length restrictions ? What is
the assumed response from the URL ?
[jm] The URL
is exchanged out of band; that's why it's "well known". Incidentally, the
URL will be the assertionProducer or the assertionConsomer unique ID. There are
no length restrictions beyond what is already imposed on URLs (2K, I think). The
URL, when dereferenced, will produce an XML document which is the provider's
metadata (which includes supported profiles, end-points, etc).
(3) Is there just 1 "well known URL" per service end point
?
[jm] The URLs are not per service
end points but per provider. Given the relationship between a provider and a
providerID, there is one well known URL per provider. If a provider chooses to
offer its services via two different providerIDs, then that is OK, but from the
standpoint of this schema/proposal, this is viewed as two distinct
providers.
(4) if I don't know the service end point how do I find
the "well known
URL" ?
[jm] The notion of a well known URL
assumes that you know it a-priori. The underlying assumption is that you need
not "discover" the URL, it is already known to you.
Anthony Nadalin | work 512.436.9568 |
cell
512.289.4122
|---------+---------------------------->
|
|
|
|
|
|
|
| 10/01/2003 06:43
|
|
|
PM
|
|---------+---------------------------->
>----------------------------------------------------------------------------------------------------------------------------------------------|
|
|
|
To:
|
|
cc:
|
| Subject:
[security-services] Groups -
sstc-saml-MetadataDiscoveryProtocols-2.0-draft-00.pdf
uploaded
|
>----------------------------------------------------------------------------------------------------------------------------------------------|
The
document sstc-saml-MetadataDiscoveryProtocols-2.0-draft-00.pdf has
been
submitted by Jahan Moreh () to the OASIS Security
Services
TC document repository.
Document Description:
This
document is a proposal for SAML 2.0 work Item W-3. It describes a
proposal
for Metadata Discovery Protocol. The proposal described in this
document
borrows extensively from the metadata discovery protocol defined
in the draft
Liberty Alliance 1.2 specifications. An MS word version is
also
available.
Download Document:
http://www.oasis-open.org/apps/org/workgroup/security/download.php/3695/sstc-saml-MetadataDiscoveryProtocols-2.0-draft-00.pdf
View Document Details:
http://www.oasis-open.org/apps/org/workgroup/security/document.php?document_id=3695
PLEASE NOTE: If the above links do not work for you, your
email
application
may be breaking the link into two pieces. You may
be able to copy and
paste
the entire link address into the address field
of your web browser.
-OASIS Open Administration
To unsubscribe
from this mailing list (and be removed from the roster of
the OASIS TC), go
to
http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php
.
To unsubscribe from this mailing list (and be
removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/security-services/members/leave_workgroup.php.
